login causing udp sento() calls to block


we have an application that MUST send an udp packet every 10ms. so we use a realtime kernel patch and a high prio thread. all well until someone tries to login using either ssh (on a different network adapter) or even the local console. then we experience hick-ups. reason is the sendto() call blocking for more than 10 ms.

does anyone have a clue what can be going on during login? or even entering a user name. or logging out. I'm confused :(
Last edited on

We would love you to help you but first provide the UDP send thread or some of the code you suspect might be the cause of this "bug".

don't think it's a bug - just something going on that I do not yet understand ...

// start thread
pthread_t my_thread;
pthread_create(&my_thread, NULL, &thread_main, NULL);

// thread main sets own prio
void* thread_main(void* ptr)
struct sched_param param;
param.sched_priority = 70;
pthread_setschedparam(pthread_self(), SCHED_FIFO, &param);

// open socket
socket_fd = socket(AF_INET, SOCK_DGRAM, 0);
int reuse_addr = 1;
setsockopt(socket_fd, SOL_SOCKET, SO_REUSEADDR, (void*)&reuse_addr, sizeof(reuse_addr));
struct sockaddr_in source;
source.sin_family = AF_INET;
source.sin_port = htons(port);
source.sin_addr.s_addr = inet_addr(source_address);
bind(socket_fd, (struct sockaddr*)&source, sizeof(source));
unsigned char time_to_live = 1;
socket_error = setsockopt(socket_fd, IPPROTO_IP, IP_MULTICAST_TTL, &time_to_live, sizeof(time_to_live));

// send messages
struct timespec t;
clock_gettime(CLOCK_MONOTONIC, &t);
// send message - this call may block for more than 10ms
int bytes_sent = sendto(socket_fd, buffer, buffer_size, 0, (struct sockaddr*)&destination, sizeof(destination));

// sleep until next message must be sent
t.tv_nsec += INTERVAL; // 10 ms
while (t.tv_nsec >= NSEC_PER_SEC)
t.tv_nsec -= NSEC_PER_SEC;
Last edited on
Are you running on a VM?
it seems selinux was my foe ... now it's switched off my application is no longer bothered by logins. even a SCHED_FIFO thread at prio 99 was affected (same calculations took more time without getting nonvoluntary context switches) while it selinux was still on ...
Thanks for the update.
Topic archived. No new replies allowed.