3

I have an ARM Linux board that is a router to 16 other boards. When all these download their updates via the router, the network routing effort starves the user space so that a software watchdog (and later on the hardware watchdog) triggers at the router.

Is there a way to renice routing efforts without packet drops?

I am aware that I could run the application with 'above normal' priority but that would have other unwanted side effects. I also have tried traffic shaping with both ingress and token bucket filters but I don't succeed even if I throttle bandwidth usage to 1-2 mbps. If I reduce the node count to five, I can serve up to 15mbps on average, 20 peak. The hardware is too slow to reach more than 30mbps on a fast ethernet link.

Topology:

  • eth0: common network at every board
  • eth1: toward FTP-gateway, only at router
  • no bridging, just IP-forwarding
Kazark
  • 969
  • 3
  • 12
  • 31
aquaherd
  • 163
  • 5
  • You may want to look into the realtime extensions. – Shawn J. Goff Mar 12 '13 at 19:02
  • 1
    Over the years, I've discovered a rough rule of thumb for bandwidth, which is that you need 1 MHz of clock for every 1 Mbit/s of data you expect that CPU to push. So, are these processors really only ~30 MHz? If they're much faster as I expect (hundreds of MHz, I'm guessing) you probably have an inefficiency in the system somewhere and need to remove that bottleneck. As always, you need to profile, monitor, and benchmark to find the CPU pig. – Warren Young Mar 12 '13 at 19:25
  • Which network driver(s) do these Ethernet ports use? And do they support ethtool? – derobert Mar 12 '13 at 19:33
  • 1
    Re: benchmarking, if [iperf](http://sourceforge.net/projects/iperf/) can get much more throughput in this system than your program, it proves the problem is your program, not the stack. – Warren Young Mar 12 '13 at 20:22
  • It has ~350 MHz, busybox, ~50MB RAM, a 2.6.30ish kernel, `tc` works and the app is mostly at ~0-15% load. I'll see what `iperf` says and keep you posted. I'll also check `ethtool`. – aquaherd Mar 12 '13 at 20:38

1 Answers1

0

I would consider an alternative to changing the routing to support 30 simultaneous downloads on a single ARM Linux board.

Have you thought about setting up a transparent Squid proxy? Those updates, rather than being downloaded 16 times, once for each board, the Squid proxy would cache the single download and serve that to each of the downstream boards.

Rob Gibson
  • 476
  • 2
  • 6
  • This is actually what I am doing. I limited the amount of simultaneous downloads for my own needs to be on the safe side. However, I am only providing infrastructure to others and I can't impose such restrictions on them. I also already cache the largest chunks. – aquaherd Mar 12 '13 at 20:28