HUB slowing down network with only one user

Hi,


let me describe my problem. I have one computer running as a linux
router/server that connects to the internet using a DSL modem. The router
is connected to an 8-port-HUB to allow other computers using the internet
and several other resources like printing, scanning or faxing. Typically
there are two other network resources connected to that HUB. The one is a
powerline-connection serving my DVD player but does not cause any traffic
as it is switched off while I'm working :-). The other one is my notebook
that I use for work and that causes some traffic load. For example I
stream audio to the server or use NFS or SMB shares that reside at the
server. Now using the HUB that network gets somewhat congested after about
10 minutes of high traffic load. For example I start XMMS to play some
files and after 10 minutes the sound gets choppy or stuck at all. The same
is with NFS or SMB shares. When moving big files the connection sucks
after about 500MB and the transfer aborts. In this case I have to unplug
and plug in again the network cable and the connection works fine again.

Therefore I tried the setup without the HUB and hooked up the notebook to
the router/server using a crossed cable. Now the network is fine,
streaming works forever and using NFS or SMB shares is way faster than
before and does not get stuck after a while.

I don't understand this behaviour. As long as there's now other traffic
the HUB should do the job. If it gets messed up sending all the traffic to
the 8 ports this shouldn't be a problem after 10 minutes but right away.

Well, maybe someone has a hint on how to solve this or what may be wrong.
I don't think that buying a switch will do any help as most of the time
only me is using the network.


Thanks for reading this little story, :-)


Paul

In comp.os.linux.networking Paul Wilhelm Elsinghorst <(E-Mail Removed)>:

[ Hub sucks ]

> Therefore I tried the setup without the HUB and hooked up the notebook to
> the router/server using a crossed cable. Now the network is fine,
> streaming works forever and using NFS or SMB shares is way faster than
> before and does not get stuck after a while.

Have encountered things like that with various cheapo crap
switches/hubs. If you unplug the hub/switch power connection for
a second and plug it in again, things usually work fine again
(for a while) until the next reset. Might be a day or so,
depending on the equipment. Possible solution, get used to
"reseting" the device once in a while or get something better,
perhaps not the cheapest (ebay) switch available.

Good luck

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 122: because Bill Gates is a Jehovah's witness
and so nothing can work on St. Swithin's day.

Maybe I install some timing device that does the power reset for me :-)!


But the HUB is a LevelOne FHU-0805TXDS. I thought LevelOne wasn't that
kind a cheap hardware, but may be someone can correct me on this. How
about AlliedTelesyn, what are You thinking of their HUB's.

In comp.os.linux.networking Paul Wilhelm Elsinghorst <(E-Mail Removed)>:
> Maybe I install some timing device that does the power reset for me :-)!

Good idea, if this is really the problem, just a remote guess.

> But the HUB is a LevelOne FHU-0805TXDS. I thought LevelOne wasn't that
> kind a cheap hardware, but may be someone can correct me on this. How
> about AlliedTelesyn, what are You thinking of their HUB's.

Pretty good experience with those small "Allied Telesyn"
hub/switches, I'd go for one of those if your problem is really
related with your hub. Can you confirm to get things working
again, as I pointed out?

--
Michael Heiming (X-PGP-Sig > GPG-Key ID: EDD27B94)
mail: echo (E-Mail Removed) | perl -pe 'y/a-z/n-za-m/'
#bofh excuse 191: Just type 'mv \* /dev/null'.

Sure I can. But I don't have to powercycle the HUB. As I wrote replugging
the network cable serves my fine. I guess unplugging the cable will have
the HUB reset the port so it comes out the same as powercycling.

Still I don't get the point why the hardware gets messed up. :-(

On Thu, 17 Mar 2005, Paul Wilhelm Elsinghorst <(E-Mail Removed)> wrote:
> Sure I can. But I don't have to powercycle the HUB. As I wrote replugging
> the network cable serves my fine. I guess unplugging the cable will have
> the HUB reset the port so it comes out the same as powercycling.
>
> Still I don't get the point why the hardware gets messed up. :-(

The point is, any hub is like a party line that works half duplex, where
both sides may attempt to communicate at the same time (client trying to
acknowledge receipt of streaming packets), which can result in collisions,
which can cause delays and retransmissions.

With direct crossover cable (no hub) or with a "switch", the connection
can be full duplex, so acknowledgements do not collide with the streaming
data (at least not within your LAN). If the switch auto senses cable
type, you do not even have to worry which type of cable (patch or xover).

In article <(E-Mail Removed)>,
Paul Wilhelm Elsinghorst wrote:

> Now using the HUB that network gets somewhat congested after about
>10 minutes of high traffic load. For example I start XMMS to play some
>files and after 10 minutes the sound gets choppy or stuck at all. The same
>is with NFS or SMB shares. When moving big files the connection sucks
>after about 500MB and the transfer aborts. In this case I have to unplug
>and plug in again the network cable and the connection works fine again.

What shows up with 'tcpdump'?

>Therefore I tried the setup without the HUB and hooked up the notebook to
>the router/server using a crossed cable. Now the network is fine,
>streaming works forever and using NFS or SMB shares is way faster than
>before and does not get stuck after a while.

If that is truly a HUB and not a switch, there shouldn't be difference.
However if I read google correctly, that's really a dual-speed switch.

>I don't understand this behaviour. As long as there's now other traffic
>the HUB should do the job.

I dunno, maybe you are passing to much traffic, and the elves inside the
switch are getting tired ;-)

>If it gets messed up sending all the traffic to the 8 ports this shouldn't
>be a problem after 10 minutes but right away.

Agreed. What does a tcpdump show? Pay attention to the TCP window sizes,
and the ACK numbers. Or does the connection simply fail, and ARP requests
are no longer answered?

Old guy

I think it is a HUB and many sites on the net state it to be a HUB. It
actually reads "8 Port 10/100Mbpss SOHO Dual-Speed Hub" on the front.

I ran tcpdump before and after it teh traffic gets choppy. Here's the
output:


Before:


08:23:54.557096 IP PWE1.45663 > Server.esound: P 1850169:1851617(1448) ack 5 win 1460 <nop,nop,timestamp 832798 8114983>
08:23:54.580321 IP Server.esound > PWE1.45663: . ack 1851617 win 4344 <nop,nop,timestamp 8114986 832798>
08:23:54.580333 IP PWE1.45663 > Server.esound: . 1851617:1853065(1448) ack 5 win 1460 <nop,nop,timestamp 832822 8114986>
08:23:54.580336 IP PWE1.45663 > Server.esound: . 1853065:1854513(1448) ack 5 win 1460 <nop,nop,timestamp 832822 8114986>
08:23:54.580338 IP PWE1.45663 > Server.esound: . 1854513:1855961(1448) ack 5 win 1460 <nop,nop,timestamp 832822 8114986>
08:23:54.603588 IP Server.esound > PWE1.45663: . ack 1855961 win 4344 <nop,nop,timestamp 8114988 832822>
08:23:54.603599 IP PWE1.45663 > Server.esound: . 1855961:1857409(1448) ack 5 win 1460 <nop,nop,timestamp 832845 8114988>
08:23:54.603601 IP PWE1.45663 > Server.esound: . 1857409:1858857(1448) ack 5 win 1460 <nop,nop,timestamp 832845 8114988>
08:23:54.603603 IP PWE1.45663 > Server.esound: . 1858857:1860305(1448) ack 5 win 1460 <nop,nop,timestamp 832845 8114988>
08:23:54.626842 IP Server.esound > PWE1.45663: . ack 1860305 win 4344 <nop,nop,timestamp 8114990 832845>
08:23:54.626855 IP PWE1.45663 > Server.esound: . 1860305:1861753(1448) ack 5 win 1460 <nop,nop,timestamp 832868 8114990>
08:23:54.626858 IP PWE1.45663 > Server.esound: P 1861753:1863201(1448) ack 5 win 1460 <nop,nop,timestamp 832868 8114990>
08:23:54.626860 IP PWE1.45663 > Server.esound: . 1863201:1864649(1448) ack 5 win 1460 <nop,nop,timestamp 832868 8114990>
08:23:54.650104 IP Server.esound > PWE1.45663: . ack 1864649 win 4344 <nop,nop,timestamp 8114993 832868>
08:23:54.650115 IP PWE1.45663 > Server.esound: . 1864649:1866097(1448) ack 5 win 1460 <nop,nop,timestamp 832891 8114993>
08:23:54.650118 IP PWE1.45663 > Server.esound: . 1866097:1867545(1448) ack 5 win 1460 <nop,nop,timestamp 832891 8114993>
08:23:54.650119 IP PWE1.45663 > Server.esound: . 1867545:1868993(1448) ack 5 win 1460 <nop,nop,timestamp 832891 8114993>
08:23:54.673379 IP Server.esound > PWE1.45663: . ack 1868993 win 4344 <nop,nop,timestamp 8114995 832891>
08:23:54.673390 IP PWE1.45663 > Server.esound: . 1868993:1870441(1448) ack 5 win 1460 <nop,nop,timestamp 832915 8114995>
08:23:54.673392 IP PWE1.45663 > Server.esound: . 1870441:1871889(1448) ack 5 win 1460 <nop,nop,timestamp 832915 8114995>
08:23:54.673394 IP PWE1.45663 > Server.esound: . 1871889:1873337(1448) ack 5 win 1460 <nop,nop,timestamp 832915 8114995>
08:23:54.696623 IP Server.esound > PWE1.45663: . ack 1873337 win 2896 <nop,nop,timestamp 8114997 832915>
08:23:54.696635 IP PWE1.45663 > Server.esound: . 1873337:1874785(1448) ack 5 win 1460 <nop,nop,timestamp 832938 8114997>
08:23:54.696637 IP PWE1.45663 > Server.esound: P 1874785:1876233(1448) ack 5 win 1460 <nop,nop,timestamp 832938 8114997>
08:23:54.719890 IP Server.esound > PWE1.45663: . ack 1876233 win 4344 <nop,nop,timestamp 8115000 832938>
08:23:54.719902 IP PWE1.45663 > Server.esound: . 1876233:1877681(1448) ack 5 win 1460 <nop,nop,timestamp 832961 8115000>
08:23:54.719904 IP PWE1.45663 > Server.esound: . 1877681:1879129(1448) ack 5 win 1460 <nop,nop,timestamp 832961 8115000>
08:23:54.719906 IP PWE1.45663 > Server.esound: . 1879129:1880577(1448) ack 5 win 1460 <nop,nop,timestamp 832961 8115000>
08:23:54.743153 IP Server.esound > PWE1.45663: . ack 1880577 win 4344 <nop,nop,timestamp 8115002 832961>
08:23:54.743164 IP PWE1.45663 > Server.esound: . 1880577:1882025(1448) ack 5 win 1460 <nop,nop,timestamp 832984 8115002>
08:23:54.743166 IP PWE1.45663 > Server.esound: . 1882025:1883473(1448) ack 5 win 1460 <nop,nop,timestamp 832984 8115002>
08:23:54.743168 IP PWE1.45663 > Server.esound: . 1883473:1884921(1448) ack 5 win 1460 <nop,nop,timestamp 832984 8115002>


After:


08:35:30.780286 IP PWE1.33322 > Server.esound: P 401256:402704(1448) ack 1 win 1460 <nop,nop,timestamp 1529127 8184600>
08:35:30.780288 IP PWE1.33322 > Server.esound: . 402704:404152(1448) ack 1 win 1460 <nop,nop,timestamp 1529127 8184600>
08:35:30.780447 IP Server.esound > PWE1.33322: . ack 401256 win 23168 <nop,nop,timestamp 8184600 1529127>
08:35:30.780457 IP PWE1.33322 > Server.esound: . 404152:405600(1448) ack 1 win 1460 <nop,nop,timestamp 1529128 8184600>
08:35:30.780615 IP Server.esound > PWE1.33322: . ack 402704 win 21720 <nop,nop,timestamp 8184600 1529127>
08:35:30.780624 IP PWE1.33322 > Server.esound: . 405600:407048(1448) ack 1 win 1460 <nop,nop,timestamp 1529128 8184600>
08:35:30.780919 IP Server.esound > PWE1.33322: . ack 402704 win 21720 <nop,nop,timestamp 8184600 1529127,nop,nop,[|tcp]>
08:35:30.780930 IP PWE1.33322 > Server.esound: . 407048:408496(1448) ack 1 win 1460 <nop,nop,timestamp 1529128 8184600>
08:35:30.781273 IP Server.esound > PWE1.33322: . ack 402704 win 21720 <nop,nop,timestamp 8184600 1529127,nop,nop,[|tcp]>
08:35:30.781284 IP PWE1.33322 > Server.esound: . 402704:404152(1448) ack 1 win 1460 <nop,nop,timestamp 1529128 8184600>
08:35:30.981360 IP PWE1.33322 > Server.esound: . 402704:404152(1448) ack 1 win 1460 <nop,nop,timestamp 1529329 8184600>
08:35:30.981749 IP Server.esound > PWE1.33322: . ack 404152 win 21720 <nop,nop,timestamp 8184621 1529329,nop,nop,[|tcp]>
08:35:30.981765 IP PWE1.33322 > Server.esound: . 404152:405600(1448) ack 1 win 1460 <nop,nop,timestamp 1529329 8184621>
08:35:30.981768 IP PWE1.33322 > Server.esound: . 408496:409944(1448) ack 1 win 1460 <nop,nop,timestamp 1529329 8184621>
08:35:30.982109 IP Server.esound > PWE1.33322: . ack 408496 win 20272 <nop,nop,timestamp 8184621 1529329>
08:35:30.982121 IP PWE1.33322 > Server.esound: . 409944:411392(1448) ack 1 win 1460 <nop,nop,timestamp 1529329 8184621>
08:35:30.982123 IP PWE1.33322 > Server.esound: . 411392:412840(1448) ack 1 win 1460 <nop,nop,timestamp 1529329 8184621>
08:35:30.982283 IP Server.esound > PWE1.33322: . ack 409944 win 18824 <nop,nop,timestamp 8184621 1529329>
08:35:30.982294 IP PWE1.33322 > Server.esound: . 412840:414288(1448) ack 1 win 1460 <nop,nop,timestamp 1529329 8184621>
08:35:30.982454 IP Server.esound > PWE1.33322: . ack 411392 win 17376 <nop,nop,timestamp 8184621 1529329>
08:35:30.982465 IP PWE1.33322 > Server.esound: . 414288:415736(1448) ack 1 win 1460 <nop,nop,timestamp 1529330 8184621>
08:35:30.982623 IP Server.esound > PWE1.33322: . ack 411392 win 17376 <nop,nop,timestamp 8184621 1529329,nop,nop,[|tcp]>
08:35:30.982633 IP PWE1.33322 > Server.esound: P 415736:417184(1448) ack 1 win 1460 <nop,nop,timestamp 1529330 8184621>
08:35:30.982791 IP Server.esound > PWE1.33322: . ack 411392 win 17376 <nop,nop,timestamp 8184621 1529329,nop,nop,[|tcp]>
08:35:30.982802 IP PWE1.33322 > Server.esound: . 417184:418632(1448) ack 1 win 1460 <nop,nop,timestamp 1529330 8184621>


All I can notice is that "ack 5 win 1460" chnages to "ack 1 win 1460". But
I don't know how to interpret this output. Do you have any hints on this?


Paul


P.S.: I'm having trouble talking to the elves :-)

Actually there's one more thing I oberserve. Before it get's choppy the server response
goes like this:


08:23:54.743153 IP Server.esound > PWE1.45663: . ack 1880577 win 4344 <nop,nop,timestamp 8115002 832961>


After that it sometimes changes to:


08:35:30.780919 IP Server.esound > PWE1.33322: . ack 402704 win 21720 <nop,nop,timestamp 8184600 1529127,nop,nop,[|tcp]>


Still I don't know about these differences. :-(

In article <(E-Mail Removed)>,
Paul Wilhelm Elsinghorst wrote:

>I think it is a HUB and many sites on the net state it to be a HUB. It
>actually reads "8 Port 10/100Mbpss SOHO Dual-Speed Hub" on the front.

All of the dual speed hardware I've ever worked with has been switches.

>I ran tcpdump before and after it teh traffic gets choppy. Here's the
>output:

OK - looks like a problem with the link. Let's see if I can do some
editing here to make this more visible. I've trimmed off the timestamp
and the letters IP.

============
Before:
PWE1.45663 > Server.esound: P 1850169:1851617(1448) ack 5 win 1460
Server.esound > PWE1.45663: . ack 1851617 win 4344
PWE1.45663 > Server.esound: . 1851617:1853065(1448) ack 5 win 1460
PWE1.45663 > Server.esound: . 1853065:1854513(1448) ack 5 win 1460
PWE1.45663 > Server.esound: . 1854513:1855961(1448) ack 5 win 1460
Server.esound > PWE1.45663: . ack 1855961 win 4344
PWE1.45663 > Server.esound: . 1855961:1857409(1448) ack 5 win 1460
PWE1.45663 > Server.esound: . 1857409:1858857(1448) ack 5 win 1460
PWE1.45663 > Server.esound: . 1858857:1860305(1448) ack 5 win 1460
Server.esound > PWE1.45663: . ack 1860305 win 4344
============

Here you can see PWE1.45663 shoveling bits to Server.esound without a
problem, and Server.esound acknowledging about every third time with
a bit count up to the latest received. The last two lines here say
"here is sequence 1858857 to 1860304" (1860305 will be the NEXT sequence
sent), and "I'm waiting for 1860305 next". The 1460 and 4344 are how far
ahead of the last ACK you are willing to accept..

============
After:
PWE1.33322 > Server.esound: P 401256:402704(1448) ack 1 win 1460
PWE1.33322 > Server.esound: . 402704:404152(1448) ack 1 win 1460
Server.esound > PWE1.33322: . ack 401256 win 23168
============

Notice it's only acking the packet above where this trace started.

============
PWE1.33322 > Server.esound: . 404152:405600(1448) ack 1 win 1460
Server.esound > PWE1.33322: . ack 402704 win 21720
PWE1.33322 > Server.esound: . 405600:407048(1448) ack 1 win 1460
Server.esound > PWE1.33322: . ack 402704 win 21720
PWE1.33322 > Server.esound: . 407048:408496(1448) ack 1 win 1460
Server.esound > PWE1.33322: . ack 402704 win 21720
PWE1.33322 > Server.esound: . 402704:404152(1448) ack 1 win 1460
PWE1.33322 > Server.esound: . 402704:404152(1448) ack 1 win 1460
Server.esound > PWE1.33322: . ack 404152 win 21720
============

PWE1.33322 continues for a bit, then resends the missing packet
Server.esound finally says OK, I heard that, but is continuing to have
trouble hearing packets from PWE1.33322. The fact that the window size
decreased from 23168 to 21720 says it heard _those_ packets, but it's
missing something earlier - hence only acking up to 402704.

What do you see in the /sbin/ifconfig output from both systems. Either
you are getting receiver errors on Server.esound, or transmitter errors
on PWE1.33322.

>All I can notice is that "ack 5 win 1460" chnages to "ack 1 win 1460". But
>I don't know how to interpret this output. Do you have any hints on this?

The 5 and 1 are ack sequence numbers. Server.esound isn't sending much data.

>P.S.: I'm having trouble talking to the elves :-)

They're sometimes hard to hear, but then are you trying to talk to them
through the same hardware that PWE1 is trying to talk to Server? ;-)

You followed up by writing:

>Actually there's one more thing I oberserve. Before it get's choppy the
>server response goes like this:
>
>08:23:54.743153 IP Server.esound > PWE1.45663: . ack 1880577 win 4344
> <nop,nop,timestamp 8115002 832961>
>
>After that it sometimes changes to:
>
>08:35:30.780919 IP Server.esound > PWE1.33322: . ack 402704 win 21720
> <nop,nop,timestamp 8184600 1529127,nop,nop,[|tcp]>

Yes, but these are different connections. Notice the different port number
that follows the name PWE1.

>Still I don't know about these differences. :-(

The man page isn't perfect, but I think it does explain this.

Old guy