[Soekris] Significant issues with 6501 upstream performance

ED Fochler soekris at liquidbinary.com
Tue Dec 22 19:32:55 CET 2015

If you have a smart switch available, as you imply, you could vlan off a segment to be your upstream interconnect; connect it in between your cable modem and net6501, and watch for traffic that way.  At the very least, having an upstream switch could let you check error counts on ethernet frames to rule out hardware problems like bad wires, port speed mismatch, etc. Then you could turn on monitoring of your upstream VLAN and wireshark it on a fast PC to see if packets are going out but not coming back, or if there are congestion messages coming in, etc.  At the very least, changing up the network connection path could reveal a bad cable or weak connection on a port.

I suggest:
cable modem -> upVLAN on smart switch -> soekris -> downVLAN 
         downVLAN includes: (monitoring port of upVLAN + lan + wifi)

You could also try setting the port speed on your uplink to 100mb FD, as that uses the port / cable in a completely different manner from Gb, and may get around a bad wire, RFI, etc.  It would also enforce a download cap that would leave some margin before you hit your enforced limit from your provider.

I still suspect that anybody who is providing such a severely asymmetric network connection has problems themselves sending information upstream.  That connection is really only good for downloading.  I’d rather have a 50/10 than 125/5.  Can you skype / facetime / video chat over that connection?

I don’t have any soekris specific advice on this.  I’m not aware of any problems that fit your description on soekris hardware.  The 6501 has good network support under OpenBSD and PFSense and I believe Linux at this time.  Though anyone troubleshooting anything on soekris hardware should try swapping out the power supply just to see if that makes a difference.  :-)  


> On 2015, Dec 22, at 11:17 AM, Thomas Fjellstrom <thomas at fjellstrom.ca> wrote:
> On Mon 21 Dec 2015 02:14:20 AM you wrote:
>> Hi Thomas,
>> [...]
>>> When I'm part of any kind of p2p "swarm", I can't upload reliably. It's so
>>> bad that I've rarely ever seen more than 20KBps per peer, and it's
>>> usually between 0 and 10KBps (5KBps is pretty average :o).
>>> I did some testing this weekend, and tried out the latest stable pfSense
>>> on it (I was running Debian Sid), and things improved a bit. Now I'm
>>> using an RT- AC66U
>> [....]
>> First of all, your network setup if not entirely clear. Is your p2p
>> client running on your Soekris net6501?
> Sorry for not including the important details.
> My network setup was like so:
> Cable Modem -> 6501-50 -> Netgear smart switch -> lan + wifi 
>> If so, is that wifi network with the Asus RT-AC66U between the Soekris
>> and the upstream network?
> Nope.
>> If not, why do you think the Soekris hardware is responsible for the
>> poor network performance?
> Remembering back, some of the problems may have appeared around the same time. 
> And I've always had issues with the soekeris, especially with linux. Back when 
> i got it, the linux support was /poor/ at best, and the bios/hardware was 
> almost worse. Who releases a product with out checking its not running at 
> optimal performance, and doesn't check the thermal profiles?
>> My first two suspects of bad network performance would be:
>> 1. Poor wifi. What is the packet loss and jitter (variation in latency)
>> between the wifi client and wifi AP? Ideally, this should be about 1 ms
>> RTT without much fluctuations, but 3 or 5 ms is usually acceptable too.
>> If you see latency over 10 ms, or over 5% packet loss, that is most
>> likely the culprit. Look into the location of the wifi, the channels
>> used by you and neighbours, etc. If you haven't done so, download a wifi
>> scanner to find out which channels are in use, and how strong they are.
>> Note that for 2.4 GHz (802.11g, 802.11n), an AP in e.g. channel 5 may
>> still interfere with channels 3 thru 7. 5 GHz (802.11n, 802.11ac) has
>> less users, but is more susceptible to interference by walls, floors and
>> doors.
> Wifi is reasonable. I'm picky about that. But the problems occur over wired 
> GbE as well.
>> 2. Network saturation because of the use of UDP-based p2p traffic. TCP
>> has a fairly commanding congestion control algorithm, which
>> significantly backs-off in case of congestion. A fair portion of p2p
>> clients uses UDP, which lacks congestion control, and may continue to
>> send traffic. Unfortunately, this often results in higher latency,
>> collisions, and ultimately collapse of performance. It certainly pays of
>> to configure your p2p client to only use at max 50-75% of your upstream
>> bandwidth capacity.
> I had my shorewall install QoS things. Did not help. My p2p use has fallen off 
> quite a lot lately. And my upstream to p2p has suffered a LARGE hit. It's 
> nearly impossible to share back.
>> Other sources might be poor TCP congestion control tuning, buffer bloat
>> or the opposite (too small buffers), poor Ethernet flow control, poor
>> upstream network. Insufficient TCP-offloading in your NIC, or -more
>> generally- not powerful enough CPU in your Soekris 6501 would be at the
>> bottom of list of suspects.
> I'm not worried about the CPU performance in the soekeris. It should be more 
> than enough. CPU use was generally very low. I'm suspecting a 
> hardware/firmware issue.
>> Hope this works.
>> Freek
> -- 
> Thomas Fjellstrom
> thomas at fjellstrom.ca
> _______________________________________________
> Soekris-tech mailing list
> Soekris-tech at lists.soekris.com
> http://lists.soekris.com/mailman/listinfo/soekris-tech

More information about the Soekris-tech mailing list