Well, thanks very much Kent, Hugo and Danny.
I went with the "never-ending blocking queues" and sentinel data approach.
When running tests with a continual stream of packets being received
3ms apart, CPU usage peaked at 15%, was usually around 7-9%, and when
deployed the packets will separated by
Thanks very much all. :) I'll have a crack this afternoon and let you know.
Kent - the increase in the queue size for the socket server is to
allow for any delay in processing packets; it has a default queue size
of 5 and then it starts rejecting packets; more of a safety policy
when reducing CPU
On Fri, 7 Apr 2006, Kent Johnson wrote:
> Hugo Gonz�lez Monteverde wrote:
> > You are not using the optional timeout and blocking which 'get' provides (!)
> >
> > Try setting it and see your CPU usage go down. This will implement
> > blocking, and the queue will be used as soon as data is there.
Hugo González Monteverde wrote:
> You are not using the optional timeout and blocking which 'get' provides (!)
>
> Try setting it and see your CPU usage go down. This will implement
> blocking, and the queue will be used as soon as data is there.Set
> block
> to True and a timeout if yo
Liam Clarke wrote:
> Each thread's run() method basically looks like this -
>
> while True:
> try:
> data = self.queue.get(False)
> self.DAO.send_data(data)
> except Empty:
> if self.shutdown:
> pr
Liam Clarke wrote:
> Hi,
>
> I've developed what would be my largest Python app to date. And, going
> from the crude Windows Task Manager, it's trying to use as much CPU
> time as it can get when it's idle.
>
> This, no doub,t is due to my design.
>
> I have an UDP socket server, a packet crunch
