PDA

View Full Version : SBG - does the UDP animation interface still work?



Triode
2005-03-03, 19:37
Hi,

I've been looking at how well I can optimise my scrolling enhancements for SBG and have found that much of the problem is possibly
caused by jitter from the tcp stack. (If I set the inter frame gap too low, the linux tcp stack sends 2 frames within one TCP
segment!)

So I was pondering whether the UDP interface on SBG which was implemented for the tentative visuliser still works? Am I right in
thinking I can fire the same frames at it that the TCP interface sends?

Adrian

rtitmuss
2005-03-03, 23:28
Triode wrote:

> Hi,
>
> I've been looking at how well I can optimise my scrolling enhancements
> for SBG and have found that much of the problem is possibly caused by
> jitter from the tcp stack. (If I set the inter frame gap too low, the
> linux tcp stack sends 2 frames within one TCP segment!)
>
> So I was pondering whether the UDP interface on SBG which was
> implemented for the tentative visuliser still works? Am I right in
> thinking I can fire the same frames at it that the TCP interface sends?
>
Yes, this interface still works on the SBG. I think you'll find using it
causes a problem if the slimserver and squeezebox are located on
different sides of a NAT router. The plan was for the SBG to send status
frames over UDP to open the reverse channel, but I don't think this is
in the current firmware.

Regards,
Richard

Triode
2005-03-04, 12:14
>> So I was pondering whether the UDP interface on SBG which was implemented for the tentative visuliser still works? Am I right in
>> thinking I can fire the same frames at it that the TCP interface sends?
>>
> Yes, this interface still works on the SBG. I think you'll find using it causes a problem if the slimserver and squeezebox are
> located on different sides of a NAT router. The plan was for the SBG to send status frames over UDP to open the reverse channel,
> but I don't think this is in the current firmware.

Are there any extra things to ensure with this?

Can I send from any udp port to 3843 and the SBG will display the frame? [Doesn't seem to work sending from 3843, wanted to check
if there is anything else to be aware of?]

Adrian

Triode
2005-03-04, 16:28
Answering my own emails - must be going mad?

Anyway I couldn't get UDP to work, but then I kicked myself - Nagle is enabled by default and not switched off for the Slimprotocol
connection.

Is there any reason why it is not dissabled (TCP_NODELAY) - there is an attempt at it commented out in Slimproto.pm.

If not could I propose the attached for Slimproto.pm

[Kdf - you may find you can scoll faster!]

kdf
2005-03-04, 16:44
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> Answering my own emails - must be going mad?
>
> Anyway I couldn't get UDP to work, but then I kicked myself - Nagle is
> enabled by default and not switched off for the Slimprotocol
> connection.
>
> Is there any reason why it is not dissabled (TCP_NODELAY) - there is an
> attempt at it commented out in Slimproto.pm.
>
> If not could I propose the attached for Slimproto.pm
>
> [Kdf - you may find you can scoll faster!]
>
alrighty-then!

You can look at the history of these things in viewcvs, using annotate link.
Looks like this was commented out WAY back at r211, along with another similar
line of code.

Log Message:

Fixed a couple of warnings messages.

Tweaked the handheld skin a bit.

Added support for raw AIFF and WAV playback.
Works for 44.1k 16bit stereo uncompressed WAV and AIFF files.
By default, transcoding is off for Squeezebox, which is unlikely to work
on a wireless network due to raw data requirements. Works well on ethernet,
and will work even better when sean pumps up the onboard buffer.

you can see the whole change here:
http://cvs.slimdevices.com/trunk/server/Slim/Networking/Slimproto.pm?view=rev&rev=211

Dean my remember why this change was done, but it was a long time ago

-kdf

kdf
2005-03-04, 21:41
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> Answering my own emails - must be going mad?
>
> Anyway I couldn't get UDP to work, but then I kicked myself - Nagle is
> enabled by default and not switched off for the Slimprotocol
> connection.
>
> Is there any reason why it is not dissabled (TCP_NODELAY) - there is an
> attempt at it commented out in Slimproto.pm.
>
> If not could I propose the attached for Slimproto.pm
>
> [Kdf - you may find you can scoll faster!]
>


well, it certainly goes faster. however, faster presents a new problem. Just
for giggles, i set it to one pixel and 0.001 rate. It now zips by, smoothly
even, but there is zero response to the remote, commands, or playback. I think
we'll need to find a reasonable lower limit and have the pref validate with a
minimum number.

-kdf

Triode
2005-03-05, 04:10
Are you using a wired connection?

We are sending ~600 byte packets. So 0.001 is one every ms = ~4.8 Mbit/s of traffic!

[For reference a pcm 44.1 16 bit stream is ~1.4M]

Bytes Bits Timout Rate
600 4800 0.001 4800000
600 4800 0.003 1600000
600 4800 0.005 960000
600 4800 0.01 480000

I've been testing on a wireless connection and can't get this close and the jitter that does occur is introduced by queuing to get
onto the wireless link. Just tried a wired one too - it flys - well done Sean on the firmware!

0.003 seems to work on a wired connection with the buffer fill remaining high and remote still working. However this is more
graphic traffic than the pcm stream I am sending!

I agree we need a reasonable minimum - say 0.005?

Dean and co - any comment on the use of TCP_NODELAY - looking back in the cvs archives this is some you started with and then
changed/remoted - was this a portability thing? If so could we put it back for all but the obscure cases.

Adrian

>
> well, it certainly goes faster. however, faster presents a new problem. Just
> for giggles, i set it to one pixel and 0.001 rate. It now zips by, smoothly
> even, but there is zero response to the remote, commands, or playback. I think
> we'll need to find a reasonable lower limit and have the pref validate with a
> minimum number.
>
> -kdf
>

Triode
2005-03-05, 04:29
On second thoughts there is a bit of logic missing here.

The sends are doing using non blocking writes so the player regulates how fast it receives by the responding with acks. If the
server trys to send faster they just fall on the floor at the server end...

Really we need to look at the size of the tcp Send-Q (netstat -t) to see what the minimum value is before the queue builds up.

I make it that 0.003 works on a wired connection - any advance?

Adrian
----- Original Message -----
From: "Triode" <triode1 (AT) btinternet (DOT) com>
To: "Slim Devices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Saturday, March 05, 2005 11:10 AM
Subject: Re: [Developers] SBG - does the UDP animation interface still work?


> Are you using a wired connection?
>
> We are sending ~600 byte packets. So 0.001 is one every ms = ~4.8 Mbit/s of traffic!
>
> [For reference a pcm 44.1 16 bit stream is ~1.4M]
>
> Bytes Bits Timout Rate
> 600 4800 0.001 4800000
> 600 4800 0.003 1600000
> 600 4800 0.005 960000
> 600 4800 0.01 480000
>
> I've been testing on a wireless connection and can't get this close and the jitter that does occur is introduced by queuing to get
> onto the wireless link. Just tried a wired one too - it flys - well done Sean on the firmware!
>
> 0.003 seems to work on a wired connection with the buffer fill remaining high and remote still working. However this is more
> graphic traffic than the pcm stream I am sending!
>
> I agree we need a reasonable minimum - say 0.005?
>
> Dean and co - any comment on the use of TCP_NODELAY - looking back in the cvs archives this is some you started with and then
> changed/remoted - was this a portability thing? If so could we put it back for all but the obscure cases.
>
> Adrian
>
>>
>> well, it certainly goes faster. however, faster presents a new problem. Just
>> for giggles, i set it to one pixel and 0.001 rate. It now zips by, smoothly
>> even, but there is zero response to the remote, commands, or playback. I think
>> we'll need to find a reasonable lower limit and have the pref validate with a
>> minimum number.
>>
>> -kdf
>>

kdf
2005-03-05, 04:44
Quoting Triode <triode1 (AT) btinternet (DOT) com>:

> Are you using a wired connection?

wireless :)

> We are sending ~600 byte packets. So 0.001 is one every ms = ~4.8 Mbit/s of
> traffic!

yup...I figured I'd go fot it :)

> [For reference a pcm 44.1 16 bit stream is ~1.4M]
>
> Bytes Bits Timout Rate
> 600 4800 0.001 4800000
> 600 4800 0.003 1600000
> 600 4800 0.005 960000
> 600 4800 0.01 480000
>
> I've been testing on a wireless connection and can't get this close and the
> jitter that does occur is introduced by queuing to get
> onto the wireless link. Just tried a wired one too - it flys - well done
> Sean on the firmware!
>
> 0.003 seems to work on a wired connection with the buffer fill remaining high
> and remote still working. However this is more
> graphic traffic than the pcm stream I am sending!
>
> I agree we need a reasonable minimum - say 0.005?
>
that would seem fair, as long as its safe. I did notice that refreshing the web
ui would slow the scrolling quite a lot. it stayed mostly smooth, though.

> Dean and co - any comment on the use of TCP_NODELAY - looking back in the cvs
> archives this is some you started with and then
> changed/remoted - was this a portability thing? If so could we put it back
> for all but the obscure cases.
>
I ran into Dean on IM earlier tonight and he has mentioned it to Sean to get
some feedback. it was so long ago, neither he nor I recall the exact reason it
was commented out in the first place. It may have even been a mistake. :)

-kdf