(Resent since I screwed up the first time) I'm getting a weird source throttling bug that I just don't know how to track down. Source is windows shoutcast 1.9.0 winamp plugin (XP up to date, and possibly others) Server is 2.3.0 It works fine for quite a while, then I get the following wierdness on tcpdump and it goes to hell: 21:03:54.601871 IP (tos 0x0, ttl 64, id 27852, offset 0, flags [DF], length: 40) server.8001 > source.2225: . [tcp sum ok] 25:25(0) ack 426502 win 62780 21:03:54.644783 IP (tos 0x0, ttl 118, id 6813, offset 0, flags [DF], length: 1500) source.2225 > server.8001: P 426502:427962(1460) ack 25 win 65511 21:03:54.644813 IP (tos 0x0, ttl 64, id 27853, offset 0, flags [DF], length: 40) server.8001 > source.2225: . [tcp sum ok] 25:25(0) ack 427962 win 164 21:03:54.648512 IP (tos 0x0, ttl 118, id 6814, offset 0, flags [DF], length: 144) source.2225 > server.8001: P 427962:428066(104) ack 25 win 65511 21:03:54.648595 IP (tos 0x0, ttl 64, id 27854, offset 0, flags [DF], length: 40) server.8001 > source.2225: . [tcp sum ok] 25:25(0) ack 428066 win 164 21:03:59.651984 IP (tos 0x0, ttl 118, id 7095, offset 0, flags [DF], length: 204) source.2225 > server.8001: . 428066:428230(164) ack 25 win 65511 So the server goes from a windowsize of 62k to 164 bytes. Once this happens, the XP stack only tries sending one packet every 5 seconds. What would cause that kind of throttling behavior? If I restart icecast it works for a while, then locks up again. I've had reports that it happens with windows icecast2 sources as well, but I wasn't able to get a tcpdump of it happening for them. I tried turning off tcp_window_scaling on linux, in case it was hitting a bug in XP, but no luck there either. Oddities: I tried setting the server to the lowest priority in linux, then running a few CPU hogging programs. That didn't cause a noticible difference. Ideas where to look? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast/attachments/20051114/29fdd64f/attachment.htm
Hi Dan, I'm not an expert on icecast however it sounds like the server is getting stuck somewhere. On Sun, 2005-11-13 at 23:23, Dan Merillat wrote:> I'm getting a weird source throttling bug that I just don't know how > to track down.<snip>> > So the server goes from a windowsize of 62k to 164 bytes. Once this > happens, the XP stack only tries sending one packet every 5 seconds. > > What would cause that kind of throttling behavior? If I restart > icecast it works for a while, then locks up again.You don't mention what version of icecast you are using or what media type you are trying to stream. That would be useful information. What does netstat report as the size of the send/receive queue? If there are non-zero counts there then the server is not processing them (perhaps fast enough).> I've had reports that it happens with windows icecast2 sources as > well, but I wasn't able to get a tcpdump of it happening for them. > > I tried turning off tcp_window_scaling on linux, in case it was > hitting a bug in XP, but no luck there either.Seems like a bad idea.> > Oddities: I tried setting the server to the lowest priority in linux, > then running a few CPU hogging programs. That didn't cause > a noticible difference. > > Ideas where to look?If your send/receive counts are non-zero you may want to run a version of the server compiled with debug and then attach to it with gdb when it gets into this condition. HTH, William.
I'm getting a weird source throttling bug that I just don't know how to track down. Source is windows shoutcast 1.9.0 winamp plugin (XP up to date, and possibly others) Server is 2.3.0 It works fine for quite a while, then I get the following wierdness on tcpdump and it goes to hell: 21:03:54.601871 IP (tos 0x0, ttl 64, id 27852, offset 0, flags [DF], length: 40) server.8001 > source.2225: . [tcp sum ok] 25:25(0) ack 426502 win 62780 21:03:54.644783 IP (tos 0x0, ttl 118, id 6813, offset 0, flags [DF], length: 1500) source.2225 > server.8001: P 426502:427962(1460) ack 25 win 65511 21:03:54.644813 IP (tos 0x0, ttl 64, id 27853, offset 0, flags [DF], length: 40) server.8001 > source.2225: . [tcp sum ok] 25:25(0) ack 427962 win 164 21:03:54.648512 IP (tos 0x0, ttl 118, id 6814, offset 0, flags [DF], length: 144) source.2225 > server.8001: P 427962:428066(104) ack 25 win 65511 21:03:54.648595 IP (tos 0x0, ttl 64, id 27854, offset 0, flags [DF], length: 40) server.8001 > source.2225: . [tcp sum ok] 25:25(0) ack 428066 win 164 21:03:59.651984 IP (tos 0x0, ttl 118, id 7095, offset 0, flags [DF], length: 204) source.2225 > server.8001: . 428066:428230(164) ack 25 win 65511 So the server goes from a windowsize of 62k to 164 bytes. Once this happens, the XP stack only tries sending one packet every 5 seconds. What would cause that kind of throttling behavior? If I restart icecast it works for a while, then locks up again. I've had reports that it happens with windows icecast2 sources as well, but I wasn't able to get a tcpdump of it happening for them. I tried turning off tcp_window_scaling on linux, in case it was hitting a bug in XP, but no luck there either. Oddities: I tried setting the server to the lowest priority in linux, then running a few CPU hogging programs. That didn't cause a noticible difference. Ideas where to look? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/icecast/attachments/20051113/1bb4b3bf/attachment-0001.htm