Set reasonable TOS bits for streaming

The Linux default packet scheduler (http://linux-ip.net/articles/Traffic-Co ... pfifo_fast) can prioritize packets if the application sets the packet header appropriately. Java has this ability using setTrafficClass() function. It would seem a good idea for the streaming socket to be set to IPTOS_THROUGHPUT.

[zip]

Done, let's see if there is a difference.

P.S. Effectively this should make streaming more reliable when the Serviio Linux machine is sending other lower priority traffic at the same time; if there is no other traffic then the result will be the same. I am unsure whether OS-X or Win32 supports this function (or whether it actually does anything on those operating systems).

Ah, I believe I have given you the wrong define; after reading http://lartc.org/howto/lartc.qdisc.classless.html, it looks like IPTOS_THROUGHPUT has the lowest priority. IPTOS_RELIABILITY (band 1) is probably the most reasonable setting for Serviio.
pfifo_fast has 3 bands starting from zero, where zero is the highest priority which is reserved for things like gaming (lowest latency).

[zip]

I hink you can set a compination of many, so I set RELIABILITY for the UPnP multicast traffic and THROUGHPUT / LATENCY for streaming. Let's see how it pans out.

Yes, you are correct, you can set multiple bits. For THROUGHPUT + MIN LATENCY, you should get band 1, and those bits do sound correct for streaming too.

Does Serviio v1.4.1 have this change?

[zip]

yes

Using MediaMonkey as a DLNA client and using Wireshark to sniff the packets, I can see TOS 0x18 (low delay / high throughput) used for HTTP (UPnP Serviio) traffic. So looks like it's working!

[npuser]

This needs to be closely monitored because it has big consequence in a home network. Serviio traffics could overrun important like VoIP packets causing VoIP calls to crackle during a serviio streaming.

Also, I see this could cause an issue during serviio online streaming or transcoding a media which resides in a network NAS( media located local to the serviio server may not run into this as they don't go to serviio transcoding engine via network). This setting seemed to send serviio traffics as a high priority from the serviio server to renders but same setting does not have any effect on media packets serviio receiving (online streams or media located in a network device to serviio server) for streaming, which could cause choppy or stop-go streaming experience.

Online or NAS located medias [normal priority] -> Serviio -> renders [high priority ] [Problem: Serviio sending to renders is a high priority but not so with serviio receiving]


note: I do not have a proof but just a thought.

Npuser

[zip]

I agree. We can start with this: viewtopic.php?f=5&t=16171

[DenyAll]

Would it be easy to include a Serviio property switch to disable this feature? This would enable testing if TOS changes are causing any issue.

<edit> Maybe this as well: viewtopic.php?f=20&t=9216&view=unread#p88947

[zip]

I've added serviio.useNetworkTOS system property for 1.4.1.1 (false by default), so that we can have some time to test this in anger, before turning on for everyone

This needs to be closely monitored because it has big consequence in a home network. Serviio traffics could overrun important like VoIP packets causing VoIP calls to crackle during a serviio streaming.

Note that VOIP packets should be using the highest priority TOS bits, whereas Serviio is using a priority below this.