Hi Gurcharan, Thanks for the clarification.
> To be precise, the only reason I have manipulated these parameters is to > be able to render the 19.2 Mbps mpeg2 stream from Seattle (233.0.73.26) > with VLC and similar higher throughput > streams. I never had a problem with vic streams, so my experiments and > observations reflected the need to optimize at higher bitrates. > Right that would make sense - It should only be an issue at higher data rates. > However, I also played around with these settings at home with my > wireless connection via Airport to roadrunner cable modem internet access, > so I was interested in optimizing both tcp and udp. I also seem to recall > something about the maxsockbuf being large enough to accommodate the tcp > send/recv space settings, but perhaps that was inaccurate. > Ok fine - yes there are a number of web pages out there about TCP tuning which suggest these sort of tweaks for high bandwidth etc. This one being quite good: http://www.macgeekery.com/tips/configuration/mac_os_x_network_tuning_guide_revisited Piers. > Fyi, > > -gurcharan > > Piers O'Hanlon wrote: > > Hi, > > > > I think the key sysctl here is this one: kern.ipc.maxsockbuf=8000000 > > which determines the max UDP buffer sizes (the others, as Chris points > > out, are only relevant to TCP). > > > > What would be useful to check is to run netstat -s on your system with > > and without the ker.ipc.maxsocketbuf setting - and look at the UDP > > section on "dropped due to full socket buffers" and see how this > > changes. > > > > However this is odd as vic does set the socket buffer sizes in the > > application. One explanation maybe that the application provided > > buffer sizes are a guide and if they're overrun then it can use more > > memory but if the default max (on my MacBook they're set to 262144) is > > too low then they will run out and hence you'll get bad video. > > > > The other thing that is strange is that this doesn't appear to happen > > on Linux (maybe it is and we haven't noticed it) but after a quick > > look at the Linux kernel it seems that the SO_RCVBUF setsocketopt() > > kernel implementation doubles the supplied value which may makes > > things ok on Linux? However the max buffer size in Linux (Ubuntu 7.10 > > anyway) is /proc/sys/net/core/wmem_max 131071 (which is lower than > > OSX)... > > > > If we find that vic's default's are too low then we can tweak them, > > though it may only be fixed on some systems but increasing the system > > maximum..... > > > > It maybe worth keeping an eye on UDP buffer overruns (use netstat -s) > > to see if this a more general problem. > > > > There's a good guide on UDP buffer sizing here: > > http://www.29west.com/docs/THPM/udp-buffer-sizing.html > > > > Piers. > > > > > > On 10/11/2007, gurcharan khanna <gsk...@cis.rit.edu> wrote: > > > >> Christoph Willing wrote: > >> > >>> On 10/11/2007, at 7:56 AM, gurcharan khanna wrote: > >>> > >>> > >>>> Mark, > >>>> > >>>> my link to the source for this seems to be broken but here's what i > >>>> have personally on my mac. > >>>> > >>>> in /etc/sysctl.conf, add these lines: > >>>> > >>>> > >>>> net.inet.tcp.recvspace=4000000 > >>>> net.inet.tcp.sendspace=4000000 > >>>> kern.ipc.maxsockbuf=8000000 > >>>> > >>> Those settings look like they may have come from: > >>> http://www.psc.edu/networking/projects/tcptune/ > >>> > >> You're right about the URL. However, the link doesn't work anymore.... > >> > >>> However, note that TCP tuning is the subject there, not UDP (which is > >>> what multicast uses). > >>> > >> Understood. However, changing these settings DOES in fact improve things > >> considerably, predictably, > >> and repeatedly. I don't quite understand it, but it does work. > >> > >> -gurcharan > >> > >>> chris > >>> > >>> > >>> > >>> > >>>> you probably have to restart to activate them. you can set these from > >>>> the command line as well but they won't "stick", but you can try out > >>>> different > >>>> settings that way. > >>>> > >>>> use: sysctl -w net.inet.tcp.recvspace=4000000 (for example) > >>>> > >>>> to set these values interactively. > >>>> > >>>> -gurcharan > >>>> > >>>> > >>>> > >>>> Leonard, Mark wrote: > >>>> > >>>>> Listers-- > >>>>> > >>>>> It was probably a year ago that a setting change for Mac OS that > >>>>> improved video quality of big video multicast streams (Gurcharan?) > >>>>> but I > >>>>> can't seem to find it any where... > >>>>> > >>>>> Can someone repost or point me towards a troubleshooting page for > >>>>> tweaks > >>>>> like this? > >>>>> > >>>>> Thanks > >>>>> Mark > >>>>> > >>>>> > >>>>> Mark Leonard > >>>>> DL Studios, UNH > >>>>> 603-862-0192 > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>> -- > >>>> ------------------------- > >>>> Gurcharan S. Khanna, Ph.D. > >>>> Director of Research Computing > >>>> Office of the Vice President for Research > >>>> > >>>> Director, Interactive Collaboration Environments Laboratory, > >>>> Center for the Advancing the Study of Cyberinfrastructure > >>>> --- > >>>> Rochester Institute of Technology > >>>> 1 Lomb Memorial Drive > >>>> Rochester, New York 14623-5603 > >>>> Phone: 585-475-7504 ~ Cell: 585-451-8370 > >>>> Email: gurcharan.kha...@rit.edu > >>>> Http: people.rit.edu/gskpop > >>>> > >>>> > >>> Christoph Willing +61 7 3365 8350 > >>> QCIF Access Grid Manager > >>> University of Queensland > >>> > >>> > >>> > >>> > >> -- > >> ------------------------- > >> Gurcharan S. Khanna, Ph.D. > >> Director of Research Computing > >> Office of the Vice President for Research > >> > >> Director, Interactive Collaboration Environments Laboratory, > >> Center for the Advancing the Study of Cyberinfrastructure > >> --- > >> Rochester Institute of Technology > >> 1 Lomb Memorial Drive > >> Rochester, New York 14623-5603 > >> Phone: 585-475-7504 ~ Cell: 585-451-8370 > >> Email: gurcharan.kha...@rit.edu > >> Http: www.rit.edu/~gskpop > >> > >> > >> > > > -- > ------------------------- > Gurcharan S. Khanna, Ph.D. > Director of Research Computing > Office of the Vice President for Research > > Director, Interactive Collaboration Environments Laboratory, > Center for the Advancing the Study of Cyberinfrastructure > --- > Rochester Institute of Technology > 1 Lomb Memorial Drive > Rochester, New York 14623-5603 > Phone: 585-475-7504 ~ Cell: 585-451-8370 > Email: gurcharan.kha...@rit.edu > Http: www.rit.edu/~gskpop > >
