PDA

View Full Version : Network Activity



paulrusnak
2006-04-06, 17:08
Is there a server setting that would slow down the massive amount of network activity between my four squeezeboxes and the server. The activity seems to be there whether the squeezeboxes are on or off. It is really bogging down the rest of my network

rudholm
2006-04-06, 17:12
There's normally not a lot of traffic to/from a SB when it's not playing music. How are you determining that there is a lot of SB/slimserver traffic? Can you be more specific about what you're seeing?

slimpy
2006-04-07, 01:19
Do you use the clock screen saver in the off mode? The clock display needs to be updated by the server every second. As long as anything is displayed on the squeezebox it must come from the server and needs to be updated. This is probably the network activity you are seeing. But updating the clock on four squeezeboxen hardly has any impact on your network. If you can play music on the squeezeboxen without dropouts then it's just not possible to bring down the network with four squeezeboxen in the off mode (even with 10BaseT). It's a whole different story if you're trying to play flac (or even wav) files on the 4 players simultaneously over a wireless network. In this case network problem would be less than surprising.

-s.

paulrusnak
2006-04-07, 05:31
I am basing my observations on the fact that the network lights on my hubs and server are always blinking like mad an I can see a marked difference in the speed of my network if I unplug all of my Squeezeboxes. It seems to have gotten much worse since I went from two Squeezeboxes to four Squeezeboxes.

The server I am running, runs on linux and if I check dmesg there will be hundreds of lines of server contacting each of the various Squeezeboxes in just a few seconds.

It also was much worse when I had them all synced. I could hardly use my network at all with four of them synced.

I am not using the clock or any screensaver and my network is a 1000BaseT.

Thanks for your help
Paul

m1abrams
2006-04-07, 05:47
There will be some traffic from server to SB even when off like others have said. It is very little traffic even to 4 SB, however it is some and will make any network activity light flash. That is not a good measure of network usage. And if you are logging ALL network traffic on the server then yes you will see several connections in your logs to your clients.

I would first look in other places to see what might be causing your issue. However have you tried shutting down slimserver and see if your network issues have subsided? I am wondering if your SB's are actually connecting to the SqueezeNetwork and that is clogging your internet connection, since that could be a much slower connection than your LAN.

Mark Lanctot
2006-04-07, 05:57
But the lights will blink if a single packet is sent.

You've done all these tests but you omitted one important thing: what's the *volume* of traffic being sent?

It's quite small. I have two Squeezeboxes, both with clock screensavers.

Total inbound traffic: 180 bytes/sec

Total outbound traffic: 204 bytes/sec

And when I turn one of the Squeezeboxes off, it's 120 in/136 out.

With 4 Squeezeboxes these numbers would double, but you'd still be well under 1 KB/s in/out combined. Without clock screensavers it would be even less. I fail to see how this could possibly impact network performance. You must have other issues.

If all 4 are streaming WAV at 1440 KB/s, with extra bandwidth requirements for control pushing each stream to say 1600 KB/s for a total of 6400 KB/s, that's not inconsequential but it could easily be handled by a gigabit network with plenty of room to spare for Internet and file transfer activity.

Average consumer gigabit equipment can only actually achieve 200 Mbps or so = 25 600 KB/s. With 4 Squeezeboxes streaming WAV, you're still only at 25% capacity.

With 4 clock screensavers consuming say 1 KB/s, you're several orders of magnitude under 1%. Without clock screensavers probably more like 500 bytes/sec.

You have gigabit networking capable of a useable 200 Mbps. Most of us are using wireless networking capable of 10-20 Mbps without issues. Again, I fail to see what the problem is. 500 B/s of 25 600 KB/s is 0.001953125%.

mherger
2006-04-07, 06:02
> I am basing my observations on the fact that the network lights on my
> hubs and server are always blinking like mad

IMHO not the most precise of benchmarks :-)

> an I can see a marked
> difference in the speed of my network if I unplug all of my
> Squeezeboxes. It seems to have gotten much worse since I went from two
> Squeezeboxes to four Squeezeboxes.

This is strange. I'm using five boxes, four of them wirelessly at 54Mb -
and do surf, print and everything on the same network. You're talking
about 1000Mb, 20x my bandwith with less players. There must something be
wrong.

> The server I am running, runs on linux and if I check dmesg there will
> be hundreds of lines of server contacting each of the various
> Squeezeboxes in just a few seconds.

dmesg is about boot messages, isn't it? I can't see anything slimserver
related in there.

Could you do some actual measures? Please try netio or something to give
some numbers.

--

Michael

-----------------------------------------------------------
Help translate SlimServer by using the
SlimString Translation Helper (http://www.herger.net/slim/)

Jacob Potter
2006-04-07, 06:54
On 4/7/06, Mark Lanctot
<Mark.Lanctot.25wahz1144414801 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> If all 4 are streaming WAV at 1440 KB/s, with extra bandwidth
> requirements for control pushing each stream to say 1600 KB/s for a
> total of 6400 KB/s, that's not inconsequential but it could easily be
> handled by a gigabit network with plenty of room to spare for Internet
> and file transfer activity.

Wrong order of magnitude :)

WAV is 1400 Kb/s, 176 KB/s.

- Jacob

geoffb
2006-04-07, 07:13
On 4/7/06, Michael Herger wrote:
> > The server I am running, runs on linux and if I check dmesg there will
> > be hundreds of lines of server contacting each of the various
> > Squeezeboxes in just a few seconds.
>
> dmesg is about boot messages, isn't it? I can't see anything slimserver
> related in there.

I think that dmesg is used for more than just boot messages; it is
general kernel output. I used it a lot trying to get a myth box up,
and it includes lots of module output during normal runtime
operations. In fact, there's a wikipedia page on it:
http://en.wikipedia.org/wiki/Dmesg

Cheers
Geoff

Mark Lanctot
2006-04-07, 07:19
On 4/7/06, Mark Lanctot
<Mark.Lanctot.25wahz1144414801 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> If all 4 are streaming WAV at 1440 KB/s, with extra bandwidth
> requirements for control pushing each stream to say 1600 KB/s for a
> total of 6400 KB/s, that's not inconsequential but it could easily be
> handled by a gigabit network with plenty of room to spare for Internet
> and file transfer activity.

Wrong order of magnitude :)

WAV is 1400 Kb/s, 176 KB/s.

- Jacob

Umm, oh yeah! Darn that capitalization!

Anyway, I erred on the far conservative side. 176 KB/s X 4 = 704 KB/s, 2.75% of typical gigabit network capacity.

geoffb
2006-04-07, 07:20
On 4/7/06, paulrusnak
<paulrusnak.25w9cb1144413301 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
> I am basing my observations on the fact that the network lights on my
> hubs and server are always blinking like mad an I can see a marked
> difference in the speed of my network if I unplug all of my
> Squeezeboxes. It seems to have gotten much worse since I went from two
> Squeezeboxes to four Squeezeboxes.
>
> The server I am running, runs on linux and if I check dmesg there will
> be hundreds of lines of server contacting each of the various
> Squeezeboxes in just a few seconds.
>
> It also was much worse when I had them all synced. I could hardly use
> my network at all with four of them synced.
>
> I am not using the clock or any screensaver and my network is a
> 1000BaseT.

I'm not a linux expert, but I'm sure there must be a ton of tools out
there that show you real-time throughput. As pointed out by others,
the actual data transfer requirements *should* be way under your
network maximums, so if you can measure the throughput as you connect
/ disconnect squeezeboxes, you can figure out if anything strange is
going on.
Then you can use something like Ethereal to pull it all apart, or at
least to post a log of traffic from one SB for others to look at.

Cheers
Geoff

Triode
2006-04-07, 10:09
Ethereal will show you exactly what is going on if you want to look, but the basics are:

SB2/SB3 - will send a display frame to the player everytime the display needs to change. If you clock displays seconds this is once per second. Display frame is 1280 bytes + some overhead. There is also a small tcp keepalive once every 2 seconds if there is no display activity - so you see packets every 2 seconds or so.

SB1G - will send a display frame to the player every second - this is 560 bytes + overhead. There is no tcp keepalive as the display frames are used as a keepalive.

These rates are so low they should not impact your network - something else is going on...

Why do you see dmesg entries all the time for this though - if its working you should see nothing. What does it say. Is there a dhcp or other problem?

Nalle Johansson
2006-04-07, 10:10
Autosvar på ditt brev
Jag befinner mig tjänsteresa och är åter den 18 april.

Extern support
Ni som har avtal med GFS hänvisas till er
support/IT-stödskonferens.
Frågor som rör Göteborgs Studentnät hänvisas till
support (AT) gfs (DOT) se

Intern support
Interna frågor från organisationen hänvisas till resp
avdelnings IT-stödskonferens eller
verksamhetschef som innehar akutmimmer till leverantörer.

Bästa hälsningar/Best Regards
Nalle Johansson

bigjules
2006-04-07, 16:57
There is also a small tcp keepalive once every 2 seconds if there is no display activity - so you see packets every 2 seconds or so.

Ignoring the display update issues, why does the squeezebox need a keepalive? What sort of connection does it maintain to the server? Surely the timeout for the connection could be made quite long, at least long enough to relieve the need for a keepalive packet.

I'm sure this has been discussed ad-infinitum.. but I couldn't find the info. Any reference would be appreciated.

Triode
2006-04-08, 03:44
Its a tcp connection. The way tcp works, you need to send data (or keepalives) to know the connection is still running. As the client is responsible for connecting to the server, the client needs a way to know it is still connected and if not attempt to reconnect - hence the keepalives.

andyg
2006-04-08, 06:17
The best tool I've found for monitoring traffic on Linux is jnettop: http://jnettop.kubs.info/

bigjules
2006-04-08, 18:12
Its a tcp connection. The way tcp works, you need to send data (or keepalives) to know the connection is still running. As the client is responsible for connecting to the server, the client needs a way to know it is still connected and if not attempt to reconnect - hence the keepalives.

TCP has a connection timeout. Why not just make that longer. Regardless of who initiated the connection, its not like the server isn't sending packets to the squeezebox all the time. Except of course when its doing nothing and nothing is displayed -- which is exactly when you'd want the connection to timeout.

radish
2006-04-08, 19:51
TCP has a connection timeout. Why not just make that longer. Regardless of who initiated the connection, its not like the server isn't sending packets to the squeezebox all the time. Except of course when its doing nothing and nothing is displayed -- which is exactly when you'd want the connection to timeout.

Except that just because the player is switched off doesn't mean the server wants to forget about it. You still want to see which players are connected, and maybe switch them on. That requires an active connection. Sure you could drop the connection on power off and bring it back on power on, but what if you couldn't? (because it wasn't there). That would lead to a UI action which couldn't be completed, and that's a Bad Thing (tm).

The real question is, why not have the keepalives? They use essentially zero bandwidth.

bigjules
2006-04-09, 00:52
Except that just because the player is switched off doesn't mean the server wants to forget about it. You still want to see which players are connected, and maybe switch them on. That requires an active connection. Sure you could drop the connection on power off and bring it back on power on, but what if you couldn't? (because it wasn't there). That would lead to a UI action which couldn't be completed, and that's a Bad Thing (tm).

The real question is, why not have the keepalives? They use essentially zero bandwidth.

The server does know the players IP. So it could just remember that.. if the player IP changes its not like the old connection remains valid anyway.

So to switch a player on.. the server could try to open a connection to it.

Some people have trouble with the keepalives preventing their server machine from going into standby.. I dont have this issue.. but I just dont see why they are necessary. I would have thought the squeezebox was a passive network device.. in that when it isn't in use it just sits there.. not impacting in any way on your network..

But I agree that the keepalives have an extremely minimal impact.

Triode
2006-04-09, 05:01
The current architecture is that clients are responsible for connecting to the server [not the other way round]

To ensure there is always a connection to receive screen updates and send keypresses, the client therefore needs to maintain the session. If the client detects the session has failed it tries to reconnect immediately and if it can't it then tries periodically. [nb the player has no notion of off and on - this is all down to the server sending different screen displays]

Hence the client needs a way of verifying the connection - this is keepalives for SB2/3 and expecting a periodic screen update for SB1/G players.

Major Hostility
2006-04-09, 18:04
My primary concern is not so much with having keep-alive packets, just the frequency. Like some other users have mentioned, when the network icon in the system tray is on 100% I normally find that an indicator that something may be running on my system that I'm not aware of, when everything else on my system should be idle.

If there was a way to reduce the keep-alives/clock update packets to something like every 10-30 seconds when the SqueezeBox is "off", rather than every second, I would personally be much happier.

Michaelwagner
2006-04-09, 18:44
I think if you change the clock settings to only show hours and minutes, it only sends the new clock once a minute.

I don't think the keep alive packets are all that frequent ... 30 second intervals? I can't recall right now.

Michaelwagner
2006-04-09, 18:47
BTW, I've noticed that the windows system tray icon for showing network activity is heavily biased. Very low but steady activity levels make it shine bright, as if megabytes per second were being transferred.

A better tool would be the performance monitor.

Mark Lanctot
2006-04-09, 18:50
I think if you change the clock settings to only show hours and minutes, it only sends the new clock once a minute.

I was using that in that graph in the first page of this thread. When I switch the display to show seconds, the outgoing activity increases to 2.7 kB/s. Still inconsequential but a definite increase. I believe that incoming traffic increases as well, but not as much.

Major Hostility
2006-04-10, 06:58
I think if you change the clock settings to only show hours and minutes, it only sends the new clock once a minute.
Thanks for pointing that out. It took me a while to find the right setting, and changing to not display seconds reduced the traffic related to the clock.



I don't think the keep alive packets are all that frequent ... 30 second intervals? I can't recall right now.

With the clock settings changed to not display seconds, I now see what appear to be the keep-alive packets once every 2 seconds. Is this the expected rate, or is there a setting that can reduce them further?



BTW, I've noticed that the windows system tray icon for showing network activity is heavily biased. Very low but steady activity levels make it shine bright, as if megabytes per second were being transferred.

A better tool would be the performance monitor.
I use the system tray icon as a general indicator, and only get concerned if it hits 100% for significant periods when I'm not expecting it, much like if the CPU meter starts hitting 100% and I'm not doing anything excessive.

Once something hits my radar, I switch over to Ethereal to track down the root cause, which is how I realized it was the SqueezeBox.

Triode
2006-04-10, 10:47
SB2/3 only sends changed screens - so depends on whether you have seconds displayed how frequently the display is updated. It also has a tcp keepalive which set at 2 seconds by the firmware of the player [i.e. can't be changed] If this were made longer then you would get a longer break before reconnecting when the network fails as the player can't attempt to reconnect without knowing the tcp session has failed.. Hence I would suggest current value is about right.

SB1/G always send at least 1 frame per second as there is no keepalive.

Major Hostility
2006-04-10, 10:57
It also has a tcp keepalive which set at 2 seconds by the firmware of the player [i.e. can't be changed]
Thank you for confirming that the regular keepalive rate is every 2 seconds.

In the future, might it be possible to lengthen this rate somewhat when the device is in the "off" mode, to something like every 10 or 30 seconds?

Please don't get me wrong. I think the SqueezeBox is a great device, but it seems rather "chatty" when it's supposed to be "off".

Triode
2006-04-10, 11:03
In the future, might it be possible to lengthen this rate somewhat when the device is in the "off" mode, to something like every 10 or 30 seconds?


Will have to leave that to someone from slim to comment on that...

However, the player doesn't actually know it is "on" or "off" (its just that the server sends different screen displays for the two modes). So I doubt it could be easily made to be adjustable.