April 2008 - Darwin-kernel - lists.apple.com

Re: Network stack/ethernet driver issues
by Michael Smith 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com On Apr 9, 2008, at 6:44 PM, rimas(a)cnmat.berkeley.edu wrote: Filing a bug is *definitely* the right thing to do. = Mike _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… I believe the relevant kernel variable is actually kern.ipc.maxsockbuf which is set by default to 8388608 in Leopard. In my code I set the size of the receive socket buffer to 2097152. Making it bigger doesn't help (since the packets aren't being discarded by the network stack but by the ethernet device). Vincent may have a better idea of how this works, but the error message you quoted looks to me more like the Yukon driver was late servicing an interrupt and the Ethernet MAC itself dropped a/some packets. I don't think (but here you should infer a large grain of salt) that a buffer further up the stack filling up would cause this - I would expect the packet to be silently dropped by the driver when it could not move it up. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by rimas＠cnmat.berkeley.edu 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Importance: Normal User-agent: SquirrelMail/1.4.9a-3.berkeley Hi Chuck, Thanks for the advice. However, there is no option to modify the ring buffer size in the info.plist file. Also, the AppleYukon2 driver is not open source (or at least not available for download from the Darwin source code page). I asked about this on one of the apple dev lists quite some time ago and was told it had to do with NDA issues with Marvell. For another project I actually ported the linux sky2 driver to OS X so that I could hack it for my nefarious purposes (a coreaudio driver to support an ethernet based audio device which required stuff to happen at primary interrupt time). I believe the relevant kernel variable is actually kern.ipc.maxsockbuf which is set by default to 8388608 in Leopard. In my code I set the size of the receive socket buffer to 2097152. Making it bigger doesn't help (since the packets aren't being discarded by the network stack but by the ethernet device). As suggested by a previous contributor to this thread, I will file a bug report and post the problem report # to this list. thanks -rimas > Try editing the info.plist file for the Yukon driver under OSX and > increase the ring buffer sizes. After making the change you will have > to execute: > > sudo touch /System/Library/Extensions > > and reboot. This will force the system to recache all drivers on boot. > > Alternately, if the driver doesn't allow modification of the ring > buffer sizes from the info.plist text file, you could download the > source (available as part of darwin) and create larger buffers inside > the driver. Recompiling it and installing it is left as an exercise > for the reader (ask back here if you get stuck). > > Lastly, make sure the net.inet.udp.* values are set to appropriate > values. Run 'sysctl -A' to see what they are under both OSX and Linux. > Feel free to try the values from Linux as your OSX values. > > There's room to tune here. Don't give up so easily. Please recall that > OSX is, out-of-the-box, tuned for a regular user. > > cr > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by Chuck Remes 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com sudo touch /System/Library/Extensions and reboot. This will force the system to recache all drivers on boot. cr _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… On Apr 9, 2008, at 6:39 PM, rimas(a)cnmat.berkeley.edu wrote: Sorry if I wasn't clear - the results I am reporting here are using a test program that only looks at the packet ID and then drops the packet. Also I get the rx buffer overrun messages even if there isn't an application running. I am using an eSATA ExpressCard and external SATA drive enclosure to log the data, they are more than fast enough (like I said everything works fine under Linux). -rimas Try editing the info.plist file for the Yukon driver under OSX and increase the ring buffer sizes. After making the change you will have to execute: Alternately, if the driver doesn't allow modification of the ring buffer sizes from the info.plist text file, you could download the source (available as part of darwin) and create larger buffers inside the driver. Recompiling it and installing it is left as an exercise for the reader (ask back here if you get stuck). Lastly, make sure the net.inet.udp.* values are set to appropriate values. Run 'sysctl -A' to see what they are under both OSX and Linux. Feel free to try the values from Linux as your OSX values. There's room to tune here. Don't give up so easily. Please recall that OSX is, out-of-the-box, tuned for a regular user. This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by Vincent Lubet 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Thanks, Vincent -rimas You do realize what the "U" in "UDP" stands for, right? -- Terry Sorry if I wasn't clear - the results I am reporting here are using a test program that only looks at the packet ID and then drops the packet. Also I get the rx buffer overrun messages even if there isn't an application running. -rimas On 09.04.2008, at 21:09, rimas(a)cnmat.berkeley.edu wrote: Greetings, Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: 00000000,00000000 skgehw - cppSkDrvEvent - SK_DRV_RX_OVERFLOW: rcv fifo overflow Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: 00000000,00000000 sky2 - RX ring overflow -- dropped a packet If you of course only write it to memory, its a different story. You can test this, by writing a sample application which only reads the id and drops the packet without doing anything else and see if that still doesn't keep up. You might have to think about how you read the UDP packets and if there's anything you can do there to improve that speed. I believe your problem however is simply disk speed. Andreas Fink Fink Consulting GmbH Global Networks Schweiz AG BebbiCell AG --------------------------------------------------------------- Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: andreas(a)fink.org www.finkconsulting.com www.global-networks.ch www.bebbicell.ch --------------------------------------------------------------- ICQ: 8239353 MSN: msn1(a)gni.ch AIM: smsrelay Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333 http://a-fink.blogspot.com/ A developers view about iPhone SDK _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Please do not take opinions expressed by Apple employees on this list to be the definitive and official Apple position. You should file a bug at https://bugreporter.apple.com/ and send the problem report # to the list so we can track it through the bug reporting system/ On Apr 9, 2008, at 5:44 PM, rimas(a)cnmat.berkeley.edu wrote: So this is considered acceptable behavior/performance and I shouldn't bother filing a bug? I realize that UDP is an "unreliable" transport but in this case the packets aren't even making it to the network stack to be discarded. In my application packet retransmission is not feasible. It seems to me that the problem is that the secondary interrupt to service the ethernet driver sometimes isn't scheduled often enough to keep up with the amount of data I'm generating. Assuming an RX receive ring buffer size of 1024 packets (I think thats what the linux driver uses) in order for an overflow to happen more than 20ms (1024 packets/50000 packets/ sec) would have to go by between when the ethernet device receives a packet and when the interrupt is processed. And also somehow things are being handled inefficiently (compared to the Linux case). Did you see the rest of my original message ? If frequently dropping packets with only 40% of the available bandwidth being utilized and no load on the machine other than an application listening for and peeking at the contents of said packets is considered OK then I will stick to Linux for my low latency, high bandwidth network applications (and encourage others to do likewise). Try using a reliable stream delivery mechanism instead. It would be a serious waste of effort to set aside a huge amount of buffer space to try and catch all packets of a type where it didn't matter if they arrived or not. On Apr 9, 2008, at 4:39 PM, rimas(a)cnmat.berkeley.edu wrote: I am using an eSATA ExpressCard and external SATA drive enclosure to log the data, they are more than fast enough (like I said everything works fine under Linux). Here's my situation: I have a custom piece of data logging hardware that generates about 50MB/sec of data and sends it out over a gigabit ethernet link as a steady stream of UDP packets (1k packet every ~20 microseconds, very periodic, not bursty at all) broadcasted to the local subnet. I want to log all this data to disk for offline analysis. As a first step I wrote a program to just listen for the UDP packets and verify that they were all being received. This is easy to do because each packet has a 16 bit sequence ID in it. Much to my dismay, I was unable to reliably achieve this. I am running 10.5.2 on a 2.33 gHz MacBook Pro with 2G of memory. After making SO_RCVBUF big enough, I was still occasionally missing a block of 100+ packets at a time. Looking in the system.log file I realized that each dropout was correlated to a message like: I think your problem is related to the fact that your userspace application can't keep up with the sent data from the kernel and thus the buffer in the kernel overruns. 50MBytes/sec of data is quite a bit and because your application writes it to disk, you need disks which can write that fast (my MacBook Pro disk can only handle something like 35MB/sec) If they are not as fast, you will naturally run out of buffer space at some time. I would suggest you redo this experiment with a striped array of firewire 800 disks. This email sent to tlambert(a)apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/vlubet %40apple.com This email sent to vlubet(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by William Kucharski 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 2.0.0.12 (X11/20080228) rimas(a)cnmat.berkeley.edu wrote: If frequently dropping packets with only 40% of the available bandwidth being utilized and no load on the machine other than an application listening for and peeking at the contents of said packets is considered OK then I will stick to Linux for my low latency, high bandwidth network applications (and encourage others to do likewise). UDP can drop as many packets as it wants to, that's why it's UDP. William Kucharski _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Granted, it shouldn't be taxing the processor as heavily as it is, and IMHO that's an issue, but you really can't complain much about dropped packets unless you start dropping TCP packets. I don't think it should be quite so easy to overflow the Yukon2 ring buffers, either, but I don't know what its design constraints were. Given Linux doesn't have the same issues, it is of course a software problem, the question is whether it's a bug or a legitimate design feature. It's more than possible Apple engineers decided it was acceptable to lose occasional UDP packets in favor of making sure some other portion of the kernel was more isochronous in nature. This email sent to site_archiver(a)lists.apple.com

1 0

Re: kernel panic on readBytes
by William Kucharski 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com User-agent: Thunderbird 2.0.0.12 (X11/20080228) Timur Alperovich wrote: struct IOPhysicalRange* range = (IOPhysicalRange*)IOMalloc(sizeof(struct IOPhysicalRange)); range->address = inStruct->offset; range->length = MEM_READ_CHUNK; William Kucharski _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… While it's not the cause of your panic, you should at the very least be checking to see whether IOMalloc returned a valid pointer or 0 before you dereference "range." But given the DAR is 0x1000, it's clear you're likely dereferencing a NULL pointer at offset 0x1000; what's at 0xB3E40? What's instruct->offset? This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by rimas＠cnmat.berkeley.edu 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Importance: Normal User-agent: SquirrelMail/1.4.9a-3.berkeley So this is considered acceptable behavior/performance and I shouldn't bother filing a bug? I realize that UDP is an "unreliable" transport but in this case the packets aren't even making it to the network stack to be discarded. In my application packet retransmission is not feasible. It seems to me that the problem is that the secondary interrupt to service the ethernet driver sometimes isn't scheduled often enough to keep up with the amount of data I'm generating. Assuming an RX receive ring buffer size of 1024 packets (I think thats what the linux driver uses) in order for an overflow to happen more than 20ms (1024 packets/50000 packets/sec) would have to go by between when the ethernet device receives a packet and when the interrupt is processed. And also somehow things are being handled inefficiently (compared to the Linux case). Did you see the rest of my original message ? If frequently dropping packets with only 40% of the available bandwidth being utilized and no load on the machine other than an application listening for and peeking at the contents of said packets is considered OK then I will stick to Linux for my low latency, high bandwidth network applications (and encourage others to do likewise). -rimas > You do realize what the "U" in "UDP" stands for, right? > > Try using a reliable stream delivery mechanism instead. It would be a > serious waste of effort to set aside a huge amount of buffer space to > try and catch all packets of a type where it didn't matter if they > arrived or not. > > -- Terry > > On Apr 9, 2008, at 4:39 PM, rimas(a)cnmat.berkeley.edu wrote: >> Sorry if I wasn't clear - the results I am reporting here are using >> a test >> program that only looks at the packet ID and then drops the packet. >> Also >> I get the rx buffer overrun messages even if there isn't an >> application >> running. >> >> I am using an eSATA ExpressCard and external SATA drive enclosure to >> log >> the data, they are more than fast enough (like I said everything works >> fine under Linux). >> >> -rimas >> >>> >>> On 09.04.2008, at 21:09, rimas(a)cnmat.berkeley.edu wrote: >>> >>>> Greetings, >>>> >>>> Here's my situation: I have a custom piece of data logging hardware >>>> that >>>> generates about 50MB/sec of data and sends it out over a gigabit >>>> ethernet >>>> link as a steady stream of UDP packets (1k packet every ~20 >>>> microseconds, >>>> very periodic, not bursty at all) broadcasted to the local subnet. >>>> I want >>>> to log all this data to disk for offline analysis. As a first >>>> step I >>>> wrote a program to just listen for the UDP packets and verify that >>>> they >>>> were all being received. This is easy to do because each packet has >>>> a 16 >>>> bit sequence ID in it. Much to my dismay, I was unable to reliably >>>> achieve this. I am running 10.5.2 on a 2.33 gHz MacBook Pro with >>>> 2G of >>>> memory. After making SO_RCVBUF big enough, I was still >>>> occasionally >>>> missing a block of 100+ packets at a time. Looking in the >>>> system.log file >>>> I realized that each dropout was correlated to a message like: >>>> >>>> Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: >>>> 00000000,00000000 >>>> skgehw - cppSkDrvEvent - SK_DRV_RX_OVERFLOW: rcv fifo overflow >>>> Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: >>>> 00000000,00000000 sky2 >>>> - RX ring overflow -- dropped a packet >>>> >>> >>> I think your problem is related to the fact that your userspace >>> application can't keep up with the sent data from the kernel and thus >>> the buffer in the kernel overruns. 50MBytes/sec of data is quite a >>> bit >>> and because your application writes it to disk, you need disks which >>> can write that fast (my MacBook Pro disk can only handle something >>> like 35MB/sec) If they are not as fast, you will naturally run out >>> of >>> buffer space at some time. I would suggest you redo this experiment >>> with a striped array of firewire 800 disks. >>> >>> If you of course only write it to memory, its a different story. >>> You can test this, by writing a sample application which only reads >>> the id and drops the packet without doing anything else and see if >>> that still doesn't keep up. You might have to think about how you >>> read >>> the UDP packets and if there's anything you can do there to improve >>> that speed. >>> >>> I believe your problem however is simply disk speed. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Andreas Fink >>> >>> Fink Consulting GmbH >>> Global Networks Schweiz AG >>> BebbiCell AG >>> >>> --------------------------------------------------------------- >>> Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333 >>> Address: Clarastrasse 3, 4058 Basel, Switzerland >>> E-Mail: andreas(a)fink.org >>> www.finkconsulting.com www.global-networks.ch www.bebbicell.ch >>> --------------------------------------------------------------- >>> ICQ: 8239353 MSN: msn1(a)gni.ch AIM: smsrelay Skype: andreasfink >>> Yahoo: finkconsulting SMS: +41792457333 >>> >>> http://a-fink.blogspot.com/ A developers view about iPhone SDK >>> >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com >> >> This email sent to tlambert(a)apple.com > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by Terry Lambert 10 Apr '08

10 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com You do realize what the "U" in "UDP" stands for, right? -- Terry -rimas On 09.04.2008, at 21:09, rimas(a)cnmat.berkeley.edu wrote: Greetings, I believe your problem however is simply disk speed. Andreas Fink Fink Consulting GmbH Global Networks Schweiz AG BebbiCell AG --------------------------------------------------------------- Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: andreas(a)fink.org www.finkconsulting.com www.global-networks.ch www.bebbicell.ch --------------------------------------------------------------- ICQ: 8239353 MSN: msn1(a)gni.ch AIM: smsrelay Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333 http://a-fink.blogspot.com/ A developers view about iPhone SDK _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/tlambert%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… Try using a reliable stream delivery mechanism instead. It would be a serious waste of effort to set aside a huge amount of buffer space to try and catch all packets of a type where it didn't matter if they arrived or not. On Apr 9, 2008, at 4:39 PM, rimas(a)cnmat.berkeley.edu wrote: Sorry if I wasn't clear - the results I am reporting here are using a test program that only looks at the packet ID and then drops the packet. Also I get the rx buffer overrun messages even if there isn't an application running. I am using an eSATA ExpressCard and external SATA drive enclosure to log the data, they are more than fast enough (like I said everything works fine under Linux). Here's my situation: I have a custom piece of data logging hardware that generates about 50MB/sec of data and sends it out over a gigabit ethernet link as a steady stream of UDP packets (1k packet every ~20 microseconds, very periodic, not bursty at all) broadcasted to the local subnet. I want to log all this data to disk for offline analysis. As a first step I wrote a program to just listen for the UDP packets and verify that they were all being received. This is easy to do because each packet has a 16 bit sequence ID in it. Much to my dismay, I was unable to reliably achieve this. I am running 10.5.2 on a 2.33 gHz MacBook Pro with 2G of memory. After making SO_RCVBUF big enough, I was still occasionally missing a block of 100+ packets at a time. Looking in the system.log file I realized that each dropout was correlated to a message like: Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: 00000000,00000000 skgehw - cppSkDrvEvent - SK_DRV_RX_OVERFLOW: rcv fifo overflow Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: 00000000,00000000 sky2 - RX ring overflow -- dropped a packet I think your problem is related to the fact that your userspace application can't keep up with the sent data from the kernel and thus the buffer in the kernel overruns. 50MBytes/sec of data is quite a bit and because your application writes it to disk, you need disks which can write that fast (my MacBook Pro disk can only handle something like 35MB/sec) If they are not as fast, you will naturally run out of buffer space at some time. I would suggest you redo this experiment with a striped array of firewire 800 disks. If you of course only write it to memory, its a different story. You can test this, by writing a sample application which only reads the id and drops the packet without doing anything else and see if that still doesn't keep up. You might have to think about how you read the UDP packets and if there's anything you can do there to improve that speed. This email sent to tlambert(a)apple.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by rimas＠cnmat.berkeley.edu 09 Apr '08

09 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com Importance: Normal User-agent: SquirrelMail/1.4.9a-3.berkeley Sorry if I wasn't clear - the results I am reporting here are using a test program that only looks at the packet ID and then drops the packet. Also I get the rx buffer overrun messages even if there isn't an application running. I am using an eSATA ExpressCard and external SATA drive enclosure to log the data, they are more than fast enough (like I said everything works fine under Linux). -rimas > > On 09.04.2008, at 21:09, rimas(a)cnmat.berkeley.edu wrote: > >> Greetings, >> >> Here's my situation: I have a custom piece of data logging hardware >> that >> generates about 50MB/sec of data and sends it out over a gigabit >> ethernet >> link as a steady stream of UDP packets (1k packet every ~20 >> microseconds, >> very periodic, not bursty at all) broadcasted to the local subnet. >> I want >> to log all this data to disk for offline analysis. As a first step I >> wrote a program to just listen for the UDP packets and verify that >> they >> were all being received. This is easy to do because each packet has >> a 16 >> bit sequence ID in it. Much to my dismay, I was unable to reliably >> achieve this. I am running 10.5.2 on a 2.33 gHz MacBook Pro with 2G of >> memory. After making SO_RCVBUF big enough, I was still occasionally >> missing a block of 100+ packets at a time. Looking in the >> system.log file >> I realized that each dropout was correlated to a message like: >> >> Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: 00000000,00000000 >> skgehw - cppSkDrvEvent - SK_DRV_RX_OVERFLOW: rcv fifo overflow >> Apr 9 13:38:51 Macintosh-6 kernel[0]: AppleYukon2: >> 00000000,00000000 sky2 >> - RX ring overflow -- dropped a packet >> > > I think your problem is related to the fact that your userspace > application can't keep up with the sent data from the kernel and thus > the buffer in the kernel overruns. 50MBytes/sec of data is quite a bit > and because your application writes it to disk, you need disks which > can write that fast (my MacBook Pro disk can only handle something > like 35MB/sec) If they are not as fast, you will naturally run out of > buffer space at some time. I would suggest you redo this experiment > with a striped array of firewire 800 disks. > > If you of course only write it to memory, its a different story. > You can test this, by writing a sample application which only reads > the id and drops the packet without doing anything else and see if > that still doesn't keep up. You might have to think about how you read > the UDP packets and if there's anything you can do there to improve > that speed. > > I believe your problem however is simply disk speed. > > > > > > > > > > Andreas Fink > > Fink Consulting GmbH > Global Networks Schweiz AG > BebbiCell AG > > --------------------------------------------------------------- > Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333 > Address: Clarastrasse 3, 4058 Basel, Switzerland > E-Mail: andreas(a)fink.org > www.finkconsulting.com www.global-networks.ch www.bebbicell.ch > --------------------------------------------------------------- > ICQ: 8239353 MSN: msn1(a)gni.ch AIM: smsrelay Skype: andreasfink > Yahoo: finkconsulting SMS: +41792457333 > > http://a-fink.blogspot.com/ A developers view about iPhone SDK > > > > > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: Network stack/ethernet driver issues
by Andreas Fink 09 Apr '08

09 Apr '08

site_archiver(a)lists.apple.com Delivered-To: darwin-kernel(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-kernel mailing list (Darwin-kernel(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0