Thanks. Yes, what I am wanting to do is to induce some packet loss at the NIC or in the kernel (while it is processing the packets) by running some high priority processes. Following is my original question:
I have two machines connected back to back over a 1 Gbps link, and am doing some file transfer experiments over UDP. The receiver is running a few cpu bound processes (userspace). As expected, the receiver incurs losses because the CPU is busy. My understanding was that these losses could occur at the following three places: 1. UDP application's socket buffer. 2. NIC's buffer. 3. During protocol processing in the kernel. But in my experiments I see only losses due to the socket buffer overflow. Could anyone please tell me the conditions under which the NIC's buffer overflows, and when does the kernel drop packets. Since I saw losses only at the socket buffer, I thought that it could be happening because the NIC interrupts must be issued at a higher priority, so they would cause any user process to yield the CPU. To see if this was correct, I thought of raising the priority of the UDP receiver application using the priocntl command. I changed its class to Real time, and set its priority to 59 (the maximum), but even then I was noticing losses only at the socket buffer. Can someone please explain if a real time process with high priority competes with the NIC interrupts, or will the NIC interrupts still cause it to yield the CPU? Thanks, Vish On Thu, Apr 22, 2010 at 12:13 PM, Jason King <ja...@ansipunx.net> wrote: > IIRC, Real time processes have higher priority than even the kernel, > so one should be _very_ careful about putting applications in the the > RT class, as a poorly written app can cause bad things to happen. > > Is there something specific you're trying to accomplish? > > > On Thu, Apr 22, 2010 at 1:57 PM, Vishal Ahuja <vahu...@gmail.com> wrote: > > Hi All, > > > > If I use the priocntl command to change the class of a process from > > 'Interactive' to 'Real time', and set its priority to 59, how does this > > process fare against other user and kernel processes in the system. > > > > Thank you > > Vish > > _______________________________________________ > > opensolaris-code mailing list > > opensolaris-code@opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/opensolaris-code > > > > >
_______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
