Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualjbadams

Posted 15 April 2014 - 02:16 AM

So I'm stuck, and can't seem to figure out what the "right way" to solve this is.

 

I'm using enet - and the "enet_host_service" which takes care of sending and receiving data takes a timeout, like 10ms or 5000ms - whatever. The problem is; how large should this be? 1ms?

 

Cause the wait freezes the rest of the thread, of course. But if I have two threads, one that reads from the top of a list(simulation) and another one that writes to the bottom of the list(network) - wouldn't that impact performance hard and in some cases cause problems with locking?

 

Another thing I thought about was using zeromq(zmq) internally as I then don't have to think about locking, but I'm very unsure about zeromq when it comes to latency.

 

Any suggestions?

 

I think what you suggested is the best. Have one thread taking care of network reads and writes (handling the Enet context) and one or however many you need for what you would like to do in terms of other processing. If you are handling messages with one thread then even if there is interlocking due to some queue issues, that should not be a big problem as it's not that heavy operation (locking the mutex) and you don't actually wait all that long as you have 1kHz at most reads from the list, and if you construct the read/write to be "instant" like I suggest below then there should be no issue of waiting.

 

I solved this by having an in process list (with messages to be sent) and one in queue list (with messages to be soon added to be sent). Like this you off-load the interlocking by only making the lock-unlock depend on a super fast pointer setting operation between two lists.

 

1 ms is good I think, depends on your latency issues.

 

PS - Also you might be too smart for your own good. You seem to be doing future-proof-development. Just wing it, implement it and see ;-)

: Restored post contents from history.


#8jbadams

Posted 13 April 2014 - 01:28 AM

So I'm stuck, and can't seem to figure out what the "right way" to solve this is.

 

I'm using enet - and the "enet_host_service" which takes care of sending and receiving data takes a timeout, like 10ms or 5000ms - whatever. The problem is; how large should this be? 1ms?

 

Cause the wait freezes the rest of the thread, of course. But if I have two threads, one that reads from the top of a list(simulation) and another one that writes to the bottom of the list(network) - wouldn't that impact performance hard and in some cases cause problems with locking?

 

Another thing I thought about was using zeromq(zmq) internally as I then don't have to think about locking, but I'm very unsure about zeromq when it comes to latency.

 

Any suggestions?

 

I think what you suggested is the best. Have one thread taking care of network reads and writes (handling the Enet context) and one or however many you need for what you would like to do in terms of other processing. If you are handling messages with one thread then even if there is interlocking due to some queue issues, that should not be a big problem as it's not that heavy operation (locking the mutex) and you don't actually wait all that long as you have 1kHz at most reads from the list, and if you construct the read/write to be "instant" like I suggest below then there should be no issue of waiting.

 

I solved this by having an in process list (with messages to be sent) and one in queue list (with messages to be soon added to be sent). Like this you off-load the interlocking by only making the lock-unlock depend on a super fast pointer setting operation between two lists.

 

1 ms is good I think, depends on your latency issues.

 

spinningcube

 

PS - Also you might be too smart for your own good. You seem to be doing future-proof-development. Just wing it, implement it and see ;-)

: Restored post contents from history.


#7spinningcube

Posted 12 April 2014 - 07:53 PM

.


#6spinningcube

Posted 17 March 2014 - 09:07 AM

So I'm stuck, and can't seem to figure out what the "right way" to solve this is.

 

I'm using enet - and the "enet_host_service" which takes care of sending and receiving data takes a timeout, like 10ms or 5000ms - whatever. The problem is; how large should this be? 1ms?

 

Cause the wait freezes the rest of the thread, of course. But if I have two threads, one that reads from the top of a list(simulation) and another one that writes to the bottom of the list(network) - wouldn't that impact performance hard and in some cases cause problems with locking?

 

Another thing I thought about was using zeromq(zmq) internally as I then don't have to think about locking, but I'm very unsure about zeromq when it comes to latency.

 

Any suggestions?

 

I think what you suggested is the best. Have one thread taking care of network reads and writes (handling the Enet context) and one or however many you need for what you would like to do in terms of other processing. If you are handling messages with one thread then even if there is interlocking due to some queue issues, that should not be a big problem as it's not that heavy operation (locking the mutex) and you don't actually wait all that long as you have 1kHz at most reads from the list, and if you construct the read/write to be "instant" like I suggest below then there should be no issue of waiting.

 

I solved this by having an in process list (with messages to be sent) and one in queue list (with messages to be soon added to be sent). Like this you off-load the interlocking by only making the lock-unlock depend on a super fast pointer setting operation between two lists.

 

1 ms is good I think, depends on your latency issues.

 

spinningcube

 

PS - Also you might be too smart for your own good. You seem to be doing future-proof-development. Just wing it, implement it and see ;-)


#5spinningcube

Posted 17 March 2014 - 09:05 AM

So I'm stuck, and can't seem to figure out what the "right way" to solve this is.

 

I'm using enet - and the "enet_host_service" which takes care of sending and receiving data takes a timeout, like 10ms or 5000ms - whatever. The problem is; how large should this be? 1ms?

 

Cause the wait freezes the rest of the thread, of course. But if I have two threads, one that reads from the top of a list(simulation) and another one that writes to the bottom of the list(network) - wouldn't that impact performance hard and in some cases cause problems with locking?

 

Another thing I thought about was using zeromq(zmq) internally as I then don't have to think about locking, but I'm very unsure about zeromq when it comes to latency.

 

Any suggestions?

 

I think what you suggested is the best. Have one thread taking care of network reads and writes (handling the Enet context) and one or however many you need for what you would like to do in terms of other processing. If you are handling messages with one thread then even if there is interlocking due to some queue issues, that should not be a big problem as it's not that heavy operation (locking the mutex) and you don't actually wait all that long as you have 1kHz at most reads from the list, and if you construct the read/write to be "instant" like I suggest below then there should be no issue of waiting.

 

I solved this by having an in process list (with messages to be sent) and one in queue list (with messages to be soon added to be sent). Like this you off-load the interlocking by only making the lock-unlock depend on a super fast pointer setting operation between two lists.

 

1 ms is good I think, depends on your latency issues.

 

spinningcube


#4spinningcube

Posted 17 March 2014 - 09:05 AM

So I'm stuck, and can't seem to figure out what the "right way" to solve this is.

 

I'm using enet - and the "enet_host_service" which takes care of sending and receiving data takes a timeout, like 10ms or 5000ms - whatever. The problem is; how large should this be? 1ms?

 

Cause the wait freezes the rest of the thread, of course. But if I have two threads, one that reads from the top of a list(simulation) and another one that writes to the bottom of the list(network) - wouldn't that impact performance hard and in some cases cause problems with locking?

 

Another thing I thought about was using zeromq(zmq) internally as I then don't have to think about locking, but I'm very unsure about zeromq when it comes to latency.

 

Any suggestions?

 

I think what you suggested is the best. Have one thread taking care of network reads and writes (handling the Enet context) and one or however many you need for what you would like to do in terms of other processing. If you are handling messages with one thread then even if there is interlocking due to some queue issues, that should not be a big problem as it's not that heavy operation (locking the mutex) and you don't actually wait all that long as you have 1kHz at most reads from the list, and if you construct the read/write to be "instant" like I suggest below then there should be no issue of waiting.

 

I solved this by having a in process list (with messages to be sent) and one in queue list (with messages to be soon added to be sent). Like this you off-load the interlocking by only making the lock-unlock depend on a super fast pointer setting operation between two lists.

 

1 ms is good I think, depends on your latency issues.

 

spinningcube


PARTNERS