9 Jun
2024
9 Jun
'24
7:01 p.m.
Shawn,
Thanks for the ideas/suggestions.
GF advertises the same bandwidth up and down. The behaviour is relatively recent, and does seem to be getting worse.
I've been running the below on bootup since at least July of 2022.
ethtool -K enp1s0 sg off tso off gro off gso off ethtool -K enp1s1 sg off tso off gro off gso off ethtool -K enp1s2 sg off tso off gro off gso off
One other datapoint, don't laugh, but I'm running Linux on a 32 bit machine as my gateway. People who have been around for a long time will not be surprised at this.
Thanks,
--
Hal Duston
hduston@gmail.com
Kansas City, MO
816-916-7219
On Sun, 09 Jun 2024 13:21:35 -0500, Shawn C. Powell wrote:
> Hi All,
>
> I'm a newbie to the list so a little hesitant to jump in :), but my Spectrum
> fibre down here (Peculiar area) exhibits an upload cap about 30 times less
> than the download bandwidth. Could that be what you are seeing?
>
> I recently installed and switched over to OpenWRT during which I was looking
> closer at bandwidth performance. I was surprised at some of the poor
> performances. I found that on on a couple machines I had to turn off TSO
> offloading (ethtool -K tso off). I found that counter-intuitive.
>
> On 6/8/24 22:09, Hal Duston wrote:
> > All,
> >
> > When I xfer the same file via sftp from the source server to the
> > source gateway I see a xfer rate of 16.7MB/s. This eliminates the
> > possibilty of the source storage being the culprit. That gets the
> > file directly adjacent to the source GF network box.
> >
> > I have tried with the destination storage being /dev/null, so no issue
> > there.
> >
> > The destination network is a consumer grade Linksys WiFi router
> > directly connected to the GF network box with my laptop directly
> > connected to the same WiFi router.
> >
> > I have tried with sftp and http and received identical results.
> >
> > The original file is compressed. I have also noticed that a parallel
> > ssh connection between the houses is very laggy during the xfer.
> >
> > I just noticed that with the two identical NICs (82541PI Gigabit) in
> > the source firewall,
> >
> > the NIC connected to my internal switch (a Linksys LGS318) shows
> > e1000: enp1s0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
> >
> > while the one connected to the GF Network box shows
> > e1000: enp1s2 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX
> >
> > <Several minutes later>
> >
> > No, that is NOT the cause. They've been that way since 2019.
> > (I checked my kernel logs)
> >
> > All servers report CPU Idle between 85% to 95% during the xfer so
> > that's also not the issue.
> >
> > This change in behaviour is fairly recent. I used to see much higher
> > transfer rates with the same HW and SW six months ago and earlier.
> >
> > Still digging ... ... ...
> >
> > Thanks,
>
> _______________________________________________
> KCLUG mailing list -- kclug@kclug.org
> To unsubscribe send an email to kclug-leave@kclug.org
> %(web_page_url)slistinfo/%(_internal_name)s