Is it better to cast from Windows or Linux based server

[Xpire]

Hi all
i wanna to make my radio station and i wonder if is it better to cast using Windows or linux Based server?
i googled for winamp run for linux and i find only one version which is 3.1 and no update for it also i googled for Shoutcast and i find version for it that run on linux but,will it ok to use linux or Windows based server? or will it ok to cast using windows or linux?
i googled and find XMMS that can used instead of winamp butIs it good or bad?
Plz tell me what is advantages and disadvantage so i can choose to by windows or linux server

Reagrds,
Xtreme

[hackerdork]

Better?? well thats all a matter of what you know and what you like.

Use winamp only on windows its not a linux application. You can live DJ using winamp (FREE) and shoutcast server on a windows box. simple eh?

However for 24/7 streaming I use linux/UNIX so when a live DJ is not logged in and broadcasting the linux box streams using sc_trans. also the servers i run are linux based as well, why have all the bloated windows crap in the way..

If you are clueless about linux, don't waste your time you will only get frustrated. You can run XMS and stream from it to a shoutcast server, just have to read all the readme files, config files and google for help.

so which is better for you? windows or linux ??

Cheers

[Xpire]

1st thanks for your reply,
i have 2 options to choose from them.
Windows or Linux
what will be your choice?!
btw, winamp can run on linux by using wine which make 32-bit platform that can run windows application on linux Box so u can run MS office too...

Regards,
Xtreme

[djSpinnerCee]

The server is such a low resource app that you could run it on the cheapest box you can find that runs either. A text editor like vi or Notepad use more resources than any DNAS ever will.

Don't let the word "server" fool you -- with respect to applications [software] it only means that it gives up [serves] information. Server, when used with respect to hardware, implies a parts list that screams reliability and capacity

The DNAS does not need server hardware, or a server-like OS -- it can get everything it needs from the cheapest hardware out there -- all the things that file servers, database servers, and application servers like mail have in common is that they require a combination of many fast disks, a ton of RAM, and good power supplies so they don't die unexpectedly -- fortunately, the DNAS is simply a network relay that uses maybe 2Mbytes of RAM -- it does not need fast access to any disk files because what it "serves" is a single network connection from the source app -- bandwidth is what it needs, but bandwidth is external and independent of the DNAS app, the OS and the hardware that it's on.

Windows is easier. I'd use which ever OS you are the most familiar with -- unless you are or want to become a UNIX guru, you'll never learn enough about linux server capabilities by simply running a DNAS.

[dotme]

Excuse me for jumping in, but I have a question.

Two servers in the same data center. One runs Linux. One run Windows. Both run only SHOUTcast streams. Both have 1Gbps cards.

Why would a Linux server's initial burst on connect be close to 2mbps, and a Windows box only 600kbps?

I've seen this in several places now, and it's driving me nuts. I need Windows boxes, but they seem to be unable to deliver enough data on initial connect to let the player take off without briefly rebuffering one time during the initial handshake.

Any clues? Is it a Windows network problem? A DNAS-for-Windows problem?

[karlH]

Originally posted by dotme
Why would a Linux server's initial burst on connect be close to 2mbps, and a Windows box only 600kbps?

I've seen this in several places now, and it's driving me nuts. I need Windows boxes, but they seem to be unable to deliver enough data on initial connect to let the player take off without briefly rebuffering one time during the initial handshake.

It's probably down to the TCP stack. Windows (by default) typically configures the max TCP window size to be fixed (the size depends on which version of windows), where as linux (by default) uses tcp window scaling or a larger max size if scaling can't be done. The 600kbps is just windows throttling the connection

You can change this via the registy (and no I don't know if a reboot is always required)

[djSpinnerCee]

Maybe this is not a divergence, since were talking about comparisons between Linux and Win, and the subsequent differences between the two ports of the SHOUTcast DNAS server apps.

The TCP window size -- in this case the TCP send window may have an impact on that initial stream burst that a listener gets upon connecting, but it also may be by design in the DNAS application.

dotme/karlH: I do a lot of fooling around with window sizes and scaling on Windows and have found that the scaling option works sometimes, but it often depends on wether the client also supports it -- with respect to the send window it can be configured on Windows [NT/2000/XP] boxes:

HKLM\System\CurrentConrolSet\Services\AFD\

You should see the keys Enum and Security. If you add a new Key called Parameters, you will be able to add the following DWORD values under:

HKLM\System\CurrentConrolSet\Services\AFD\Parameters\

DefaultReceiveWindow
Value Type: REG_DWORD
Default: 8192
Description: The number of receive bytes AFD will buffer on a connection before imposing flow control. For some applications, a larger value here will give slightly better performance at the expense of increased resource utilization. Note that applications can modify this value on a per-socket basis with the SO_RCVBUF socket option.

DefaultSendWindow
Value Type: REG_DWORD
Default: 8192
Description: Similar to DefaultReceiveWindow, but for the send side of connections.

Just like the well-known RWIN value found in

HKLM\System\CurrentConrolSet\Services\TCPIP\Parameters\TCPWindowSize

which only overrides the DefaultReceiveWindow set in the AFD key, the values you use should be a multiple of the interface MTU-40 [called MSS] - for Ethernet, 1x would be 1460.

The maximum value is 65535, and the minimum is the MSS.

For a server, you are interested in the send window, a client reports its receive window to the server -- in real time, both window sizes for a connection are negotiated such that client and server report their maximums and the lowest value will be used.

A lot of things can influence how effective changing these values will be, since the application, the DNAS server software in our case, can also configure the window sizes internally, as can the client listen app. I don't know if it does or not.

So dotme, if you're testing using the same client, try tweaking the send window on the Win box -- The box needs to be rebooted for the change to be realized but it will pay off if you can make a significant change.

If you don't notice any change, it may just be a difference in the DNAS code logic from one OS port to the other. This setting is a global value, so it will impact (and can improve) HTTPd performance as well.

I also created a list of many of the Windows TCP stack regkeys that I have found useful:

http://cjw.servehttp.com:11423/TCPRegKeys.html

It's actually excerpts from a very old doc, written when WinNT4 was the Cadillac in the WinOS stable, but it is still relevant and useful because WinXP and 2000 are still NT under the skin (that is, they share the exact same registry).

[dotme]

Wow - thanks for the help! I don't know why I missed the replies, but I'll look at this on the weekend when I can take a box offline for a bit.

I ran tests Monday night at RTB after working to establish two servers in the same data center with the same relay source. I confirmed what I had suspected as far as a performance difference. Here are the results if you're interested.

http://www.asfradio.com/tests.htm

A picture says a thousand words. Both boxes deliver a pretty solid 192kbps after connect, but the burst on Windows is much lower. Low enough for a player to momentarily pause to rebuffer on an initial connect.

I will post back after the weekend just to let you know if I made any progress with the registry tweaks.

[WCFM]

This is essential if you are running a server 24/7 on Windows: http://www.xpmaximized.com/archives/...rebooting.html

Otherwise it'll restart on you randomly (whenever it updates something "critical"), and you'll lose people and a spot until you go again. I don't know how many times that happened and got to hear from angry DJ's.

[FS-Randy]

Originally posted by dotme
Wow - thanks for the help! I don't know why I missed the replies, but I'll look at this on the weekend when I can take a box offline for a bit.

I ran tests Monday night at RTB after working to establish two servers in the same data center with the same relay source. I confirmed what I had suspected as far as a performance difference. Here are the results if you're interested.

http://www.asfradio.com/tests.htm

A picture says a thousand words. Both boxes deliver a pretty solid 192kbps after connect, but the burst on Windows is much lower. Low enough for a player to momentarily pause to rebuffer on an initial connect.

I will post back after the weekend just to let you know if I made any progress with the registry tweaks.

John,

The reg. tweaks will not likely help. In fact they may harm other services. Windows Server 2003 TCP stack is fairly well optimized.

The issue you are experiencing with Shoutcast, is a Win32 Shoutcast issue. It has nothing to do with Windows. The primary reason is that the Sleep Timer function is completely broken, and the default setting (1000mS) is too high to support high data rates.

Play with the Sleep Timer in Linux, and see if you can recreate the issue.

[djSpinnerCee]

FS-Randy: You're probably right about everything except:

Originally posted by FS-Randy
...Windows Server 2003 TCP stack is fairly well optimized...

Nothing about Windows is ever "optimized" out of the box -- Windows optimization is almost always conservative, favoring interface performance and resource conservation over daemon (background) and kernel performance, compared to *NIX, which tends to start on the aggressive side with respect to kernel function.

* Huge gains in Windows performance can be gained with just a little tweaking.

[FS-Randy]

Originally posted by djSpinnerCee
FS-Randy: You're probably right about everything except:



Nothing about Windows is ever "optimized" out of the box -- Windows optimization is almost always conservative, favoring interface performance and resource conservation over daemon (background) and kernel performance, compared to *NIX, which tends to start on the aggressive side with respect to kernel function.

* Huge gains in Windows performance can be gained with just a little tweaking.

You're right... nothing is perfectly optimized. I guess what I was saying is that Windows Server is well optimized out the box for some tasks. Shoutcast might not be one of them =)

John seems to have found/tested some useful tweaks to improve shoutcast performance. Kudos!

[dotme]

Originally posted by FS-Randy
John seems to have found/tested some useful tweaks to improve shoutcast performance. Kudos!

My sincere thanks to karlH, djSpinnerCee, and FS-Randy for the sanity check.

By making modest changes to the Winsock Send Window and the TCP Windows, I seem to have achieved the boost on the "burst on connect" I was looking for. I have not seen any adverse effect on stability under load yet - but I'll be watching things closely this week to make sure the changes don't overtax the server resources when it's getting hammered. Scalability is important too...lol

There's always that concern when you play with the defaults that something you tweak may have adverse consequences elsewhere. If things stay good for the next week or two, I'll consider it a success.

[hackerdork]

hmm.

The larger the windows size the more CPU is used to fragment the frames into standard Ethernet 1581 bytes, if you jack around with the MTU size your routers and switches will give you shit unless they support jumbo frame.

I leave well enough alone and stay with UNIX/Linux.

~ d

[Busby]

Maybe this is not a divergence, since were talking about comparisons between Linux and Win, and the subsequent differences between the two ports of the SHOUTcast DNAS server apps.

The TCP window size -- in this case the TCP send window may have an impact on that initial stream burst that a listener gets upon connecting, but it also may be by design in the DNAS application.

dotme/karlH: I do a lot of fooling around with window sizes and scaling on Windows and have found that the scaling option works sometimes, but it often depends on wether the client also supports it -- with respect to the send window it can be configured on Windows [NT/2000/XP] boxes:

HKLM\System\CurrentConrolSet\Services\AFD\

You should see the keys Enum and Security. If you add a new Key called Parameters, you will be able to add the following DWORD values under:

HKLM\System\CurrentConrolSet\Services\AFD\Parameters\

DefaultReceiveWindow
Value Type: REG_DWORD
Default: 8192
Description: The number of receive bytes AFD will buffer on a connection before imposing flow control. For some applications, a larger value here will give slightly better performance at the expense of increased resource utilization. Note that applications can modify this value on a per-socket basis with the SO_RCVBUF socket option.

DefaultSendWindow
Value Type: REG_DWORD
Default: 8192
Description: Similar to DefaultReceiveWindow, but for the send side of connections.

Just like the well-known RWIN value found in

HKLM\System\CurrentConrolSet\Services\TCPIP\Parameters\TCPWindowSize

which only overrides the DefaultReceiveWindow set in the AFD key, the values you use should be a multiple of the interface MTU-40 [called MSS] - for Ethernet, 1x would be 1460.

The maximum value is 65535, and the minimum is the MSS.

For a server, you are interested in the send window, a client reports its receive window to the server -- in real time, both window sizes for a connection are negotiated such that client and server report their maximums and the lowest value will be used.

A lot of things can influence how effective changing these values will be, since the application, the DNAS server software in our case, can also configure the window sizes internally, as can the client listen app. I don't know if it does or not.

So dotme, if you're testing using the same client, try tweaking the send window on the Win box -- The box needs to be rebooted for the change to be realized but it will pay off if you can make a significant change.

If you don't notice any change, it may just be a difference in the DNAS code logic from one OS port to the other. This setting is a global value, so it will impact (and can improve) HTTPd performance as well.

I also created a list of many of the Windows TCP stack regkeys that I have found useful:

http://cjw.servehttp.com:11423/TCPRegKeys.html

It's actually excerpts from a very old doc, written when WinNT4 was the Cadillac in the WinOS stable, but it is still relevant and useful because WinXP and 2000 are still NT under the skin (that is, they share the exact same registry).

Sorry to revisit this after so long, but I now have a new server (Win 2019) and I'm having the same problem over again.

Last time I had somone who was a guru who made the registry change for me, but this time I will have to do it myself.

I've checked the setting on the old (Win 2003) server and the registry entry says "Name: DefaultSendWindow Type:REG_DWORD Data: 0x0000ffff (65535)

I have navigated to the same Reg location on my Win 2019 box and tried to replicate the data entry without success.

It would be great if someone could talk me through the steps of setting the entry please.