Hi,
First of all, I wouldn't play with thread priorities unless absolutely > needed. Agreed :) > Second, are you using two threads just because you expect to have > better performance using them? If so, I would just try to remove them and > use one single thread to dump to disk, and see what happens. The perf gain > that you might achieve using two threads might be completely lost by the > fact that you need to copy packets and you have synchronization to manage > the shared queue. From the synchronization point of view, you could use STM (Software Transactional Memory) to get rid of the lock mechanisms (see glib and its atomic operations for portable CAS operations). From the copy point of view, I'm not seeing exactly the perf gain you might have by dumping the packet directly to the disk i.s.o. copying in main memory. To copy it to the disk, it is probable that the first packets would be copied into the disk buffer before being really dumped to the disk, which /might/ be quicker than copy it to the memory because there wouldn't be a page fault (and is in kernel-only space). But I guess that depending on the network bandwidth, the copy will be much slower than copying to the memory (without speaking about raid solutions) because the disk buffer will be full at some point. Am I missing something? On the other hand, I have some others doubts : - How many CPU do you have? And, as Gianluca asked you before, is your consumer thread heavy? I'm just asking 'cause I guess that if you have only one CPU and that the consumer thread is resources consuming, it might be a problem. Two threads on one processor is not really better than one monolithic process. (It is in fact probably worst because of the synchronization used. :)) Regards, Sebastien Tandel
_______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
