Good day Gurux Community
I am using the C# application "Gurux.DLMS.Server.Example.Net" and the Python project "Gurux.DLMS.Client.Example.python" from the Gurux Github for a thesis in my studies. I noticed that the latencies are roughly different. In test measurements where 1000 load profiles were transferred, it took between 23 and 103 seconds. I am puzzling over the reason. Is there a logical explanation for this phenomenon?
Thanks in advance for the answers.
It's hard to say, but usually, the reason is in the garbage collection or TCP/IP connection. Do you have 1000 different load profiles or do you have 1000 rows in your profile?
Hello Mikko
Thank you for your answer. I have 1000 rows in one load profile.
I have done some research. I could explain the big differences by timeouts in the TCP/IP connection (as you mentioned). However, is it possible that the garbage collection makes that much of a difference? I have a graph here for illustration with minimum, maximum and median delay as a function of packet size. I am generally amazed that communication takes so long (e.g. about 16 seconds when transmitting only one row).
Kind regards from Switzerland
Manuel
The garbage collection might affect a little bit, but not so much. 16 seconds sounds a long time for reading a one row. I did test this and it takes about 6 ms to read one row.
Reading all the rows from the buffer (10000 rows) takes about 11 seconds.
start = time.time_ns()
cells = self.read(pg, 2)
end = time.time_ns()
print(str((end - start)/1000000))
This will take a long time because there is a lot of data moved between the client and server.
Hello
I have expressed myself somewhat unclearly. By "I am generally amazed that communication takes so long (e.g. about 16 seconds when transmitting only one row)." I meant the total time for data retrieval (from communication establishment to data display).
Kind regards
Manuel
I believe that you are reading the association view. If you save that and read only data that you want to the reading time is much smaller.
Try to add -o argument like this:
-o association.xml
It will read the association view and save it for the file. The next read is faster. Have you modified the client example? The client example reads all the data from the meter and that is taking a long time.
Hello Mikko
Thank you for your answer. Saving the association view sounds like a good idea, thanks! Besides project specific adjustments I deleted the method "self.readScalerAndUnits()" and the method "self.getReadOut()" in the readAll() method from the GXDLMSReader.py. As far as I could interpret, this is the minimum configuration of the readAll() method to read the load profile.
Kind regards
Manuel
Note that the might be multiple profile generic objects on the meter and this approach will read them all. Remove profile generic objects that you don't need from the saved association file.
Hi,
Hi,
It's hard to say, but usually, the reason is in the garbage collection or TCP/IP connection. Do you have 1000 different load profiles or do you have 1000 rows in your profile?
BR,
Mikko
Hello Mikko
Hello Mikko
Thank you for your answer. I have 1000 rows in one load profile.
I have done some research. I could explain the big differences by timeouts in the TCP/IP connection (as you mentioned). However, is it possible that the garbage collection makes that much of a difference? I have a graph here for illustration with minimum, maximum and median delay as a function of packet size. I am generally amazed that communication takes so long (e.g. about 16 seconds when transmitting only one row).
Kind regards from Switzerland
Manuel
Hi,
Hi,
The garbage collection might affect a little bit, but not so much. 16 seconds sounds a long time for reading a one row. I did test this and it takes about 6 ms to read one row.
start = time.time_ns()
cells = self.readRowsByEntry(pg, 1, 1)
end = time.time_ns()
print(str((end - start)/1000000))
Reading all the rows from the buffer (10000 rows) takes about 11 seconds.
start = time.time_ns()
cells = self.read(pg, 2)
end = time.time_ns()
print(str((end - start)/1000000))
This will take a long time because there is a lot of data moved between the client and server.
BR,
Mikko
Hello
Hello
I have expressed myself somewhat unclearly. By "I am generally amazed that communication takes so long (e.g. about 16 seconds when transmitting only one row)." I meant the total time for data retrieval (from communication establishment to data display).
Kind regards
Manuel
Hi Manuel,
Hi Manuel,
I believe that you are reading the association view. If you save that and read only data that you want to the reading time is much smaller.
Try to add -o argument like this:
-o association.xml
It will read the association view and save it for the file. The next read is faster. Have you modified the client example? The client example reads all the data from the meter and that is taking a long time.
BR,
Mikko
Hello Mikko
Hello Mikko
Thank you for your answer. Saving the association view sounds like a good idea, thanks! Besides project specific adjustments I deleted the method "self.readScalerAndUnits()" and the method "self.getReadOut()" in the readAll() method from the GXDLMSReader.py. As far as I could interpret, this is the minimum configuration of the readAll() method to read the load profile.
Kind regards
Manuel
Hi,
Hi,
Note that the might be multiple profile generic objects on the meter and this approach will read them all. Remove profile generic objects that you don't need from the saved association file.
BR
Mikko
Hello Mikko
Hello Mikko
Thanks for the tip, I will adjust that. For me, the topic has thus settled.
Kind regards
Manuel