the fairness among multiple sender sessions. #66
Comments
|
One thing you may want to try is to use the following approach for enqueuing new data objects if e in ('TX_QUEUE_EMPTY') : I.e., only use TX_QUEUE_EMPTY as the trigger for enqueuing data. TX_OBJECT_SENT is more of an informational notification for applications wishing to know when the sender has made through at least one pass of initial transmission of data for an object. And TX_OBJECT_PURGED is intended as a notification the application can use when it is safe to deallocate resources referenced by a NORM tx object (e.g., a chunk of memory in the case of NORM_OBJECT_DATA or a file in the case of NORM_OBJECT_FILE). This might help with the fairness issue since I think the pattern you are using quickly ramps up activity on the first session 's1' and session 's2' tends to no get serviced as much as a result and may end up ramping up very slowly. What you may also want to do is have your code enqueue multiple data objects to both sessions at start up. If you keep both sessions transmission queues filled up, the underlying NORM code should be giving both sessions somewhat round-robin service. It could also be a better approach for this case to use multiple NormInstances, on per session, and then the operating system scheduling would probably keep the load balanced among the sessions. This is not something I've looked at closely with the NORM code and there could be issues under different conditions in addition to what you've identified here where sessions are not evenly/fairly serviced. One thing that perhaps could be done is updating the NormEvent queue to make sure that events for different sessions are alternated. Perhaps with a NormEvent queue per session and round-robin service of those queues ... I really appreciate the degree of regression testing you have been conducting here and apologize that my schedule has not let me keep up with addressing all of your good suggestions here more quickly. |
|
Yes, only use TX_QUEUE_EMPTY as the trigger for enqueuing data makes two session send data! if event.type ==EventType.TX_QUEUE_EMPTY :
result = event.session.dataEnqueue(data= data )
elif event.type == EventType.TX_OBJECT_PURGED:
if event.session == s1:
s1count +=1
elif event.session == s2:
s2count +=1
print ( f"s1: {s1count}, s2:{s2count}")Env: 1Gbps LAN, 2 Win10PC ; 1 sender with 2 sender session, 2 receiver each with one receiver session: session.setTxRateBounds(rateMin=-1, rateMax= 300_000_000)3, with setting |
|
3 sender sessions, setting rateMax ==200Mbps, object sended: |
|
So many warnings: Linux: Win10: |
|
Those warnings are fairly benign just indicating that the underlying transmit socket buffer is full and that the code will need to "try again" to send a packet. At 3 sessions time 300 Mbps each, you are getting close to the capacity of the 1 Gbps LAN. At higher data rates larger socket buffer sizes can help when the user-space code is getting more "bursty" scheduling on your operating system. The printout of the warnings could impact performance when the debug level is set high enough for those to be displayed. I can't recall off the top of my head what debug level those warnings are output, but it it's happening at too low a debug level useful for debugging other issues, it's possible they could be raised. |
|
Another work around for this issue would be to use a separate NormInstance for each Session ... then fairness is really dictated by operating system scheduling of each of the threads (Each NormInstance corresponds to an operating system thread). One improvement I've thought about is using system calls to balance sessions over instances/threads under the hood so the user of the API doesn't have to concern themselves with that detail. |
In the following code, I create two sessions in one process, only session s1 keeps send data:
Output:
The text was updated successfully, but these errors were encountered: