Arpeggio concerto
Polar_888
Posted messages
257
Registration date
Status
Member
Last intervention
-
Polar_888 Posted messages 257 Registration date Status Member Last intervention -
Polar_888 Posted messages 257 Registration date Status Member Last intervention -
Hello,
I use the Arpege Concerto software that allows managing the absences of people.
This software operates on TSE.
It sometimes crashes when we perform actions like providing a reason for absence.
We then find ourselves disconnected from the software without closing it properly.
I wonder if this is due to a problem with the network. (Insufficient bandwidth?)
What do you think?
Thank you
I use the Arpege Concerto software that allows managing the absences of people.
This software operates on TSE.
It sometimes crashes when we perform actions like providing a reason for absence.
We then find ourselves disconnected from the software without closing it properly.
I wonder if this is due to a problem with the network. (Insufficient bandwidth?)
What do you think?
Thank you
Configuration: Windows XP Mozzilla Firefox
8 answers
It's difficult to give an opinion on this matter since a much more in-depth diagnosis of the problem would be needed.
We would need to know the architecture in more detail to put forward any hypotheses.
We would need to know the architecture in more detail to put forward any hypotheses.
First of all, thank you for your response.
The architecture I'm working on is a city.
I sniffed the traffic using Wireshark/Ethereal on one of the (many) sites where the software crashes.
I am receiving messages of this type in a relatively large quantity (almost 1/3):
132 8.902833 10.1.***.** 10.60.**.* TPKT [TCP Previous segment lost] Continuation
133 8.902867 10.60.**.* 10.1.***.** TCP [TCP Dup ACK 131#1] oraclenames > ms-wbt-server [ACK] Seq=3006 Ack=32076 Win=65535 Len=0 SLE=33536 SRE=34757
134 8.905082 10.1.***.** 10.60.20.1 TPKT [TCP Out-Of-Order] Continuation
I also receive frames of this type:
11818 689.376478 10.1.***.*** 10.60.**.* TCP [TCP Keep-Alive] microsoft-ds > jlicelmd [ACK] Seq=1 Ack=1 Win=62874 Len=1
11819 689.376496 10.60.**.* 10.1.***.*** TCP [TCP Keep-Alive ACK] jlicelmd > microsoft-ds [ACK] Seq=1 Ack=2 Win=64289 Len=0
Do you think these messages could be the cause of my problem?
Some messages are not arriving in the correct order if I understood correctly..
Thank you
The architecture I'm working on is a city.
I sniffed the traffic using Wireshark/Ethereal on one of the (many) sites where the software crashes.
I am receiving messages of this type in a relatively large quantity (almost 1/3):
132 8.902833 10.1.***.** 10.60.**.* TPKT [TCP Previous segment lost] Continuation
133 8.902867 10.60.**.* 10.1.***.** TCP [TCP Dup ACK 131#1] oraclenames > ms-wbt-server [ACK] Seq=3006 Ack=32076 Win=65535 Len=0 SLE=33536 SRE=34757
134 8.905082 10.1.***.** 10.60.20.1 TPKT [TCP Out-Of-Order] Continuation
I also receive frames of this type:
11818 689.376478 10.1.***.*** 10.60.**.* TCP [TCP Keep-Alive] microsoft-ds > jlicelmd [ACK] Seq=1 Ack=1 Win=62874 Len=1
11819 689.376496 10.60.**.* 10.1.***.*** TCP [TCP Keep-Alive ACK] jlicelmd > microsoft-ds [ACK] Seq=1 Ack=2 Win=64289 Len=0
Do you think these messages could be the cause of my problem?
Some messages are not arriving in the correct order if I understood correctly..
Thank you
Hello,
The fact that messages do not arrive at the other end is not necessarily a sign of a problem.
However, if this occurs continuously and you have many 'lost' and 'duplicate' messages, it likely indicates that a path/device being used is problematic: packet loss, latency.
This could be explained by QoS being forced to be aggressive due to traffic being too high compared to the available bandwidth... or simply due to a faulty connection (cabling, negotiation, etc.) which could be causing packet loss.
Have you traced the server and examined all the links traversed? Is this path always the same (no port flapping that would cause rerouting, latency or packet loss?), what results do you get from a long ping with max MTU? Is the latency okay? Any losses? ...
The fact that messages do not arrive at the other end is not necessarily a sign of a problem.
However, if this occurs continuously and you have many 'lost' and 'duplicate' messages, it likely indicates that a path/device being used is problematic: packet loss, latency.
This could be explained by QoS being forced to be aggressive due to traffic being too high compared to the available bandwidth... or simply due to a faulty connection (cabling, negotiation, etc.) which could be causing packet loss.
Have you traced the server and examined all the links traversed? Is this path always the same (no port flapping that would cause rerouting, latency or packet loss?), what results do you get from a long ping with max MTU? Is the latency okay? Any losses? ...
Thank you for your response
what do you mean by port bumps?
I will try to do what you say for the tests.
For the ping test:
I had no loss for 250 frames sent, each containing 1500 bytes (MTU)
For the traceroute:
1 <1 ms <1 ms <1 ms 10.11.***.***
2 <1 ms <1 ms <1 ms 10.39.*.**
3 <1 ms <1 ms 1 ms 10.39.***.**
4 2 ms <1 ms <1 ms 10.39.***.***
5 3 ms 2 ms <1 ms 86.79.*.*
6 163 ms 17 ms 20 ms 86.78.**.**
7 18 ms 15 ms 13 ms 10.60.**.*
These results seem correct ...
The problem may also come from the application on the client machine ... But how can we be sure of that?
What happens concretely during a modification is that the software quits suddenly without warning but the action "that caused the crash" is still taken into account.
This problem does not occur on all sites... This leads me to think that the problem lies with the network.
What do you think?
what do you mean by port bumps?
I will try to do what you say for the tests.
For the ping test:
I had no loss for 250 frames sent, each containing 1500 bytes (MTU)
For the traceroute:
1 <1 ms <1 ms <1 ms 10.11.***.***
2 <1 ms <1 ms <1 ms 10.39.*.**
3 <1 ms <1 ms 1 ms 10.39.***.**
4 2 ms <1 ms <1 ms 10.39.***.***
5 3 ms 2 ms <1 ms 86.79.*.*
6 163 ms 17 ms 20 ms 86.78.**.**
7 18 ms 15 ms 13 ms 10.60.**.*
These results seem correct ...
The problem may also come from the application on the client machine ... But how can we be sure of that?
What happens concretely during a modification is that the software quits suddenly without warning but the action "that caused the crash" is still taken into account.
This problem does not occur on all sites... This leads me to think that the problem lies with the network.
What do you think?
Hello,
I use the term 'bagot' to refer to a port that regularly switches from up to down: negotiation issues, cabling problems, etc.
250 frames is a bit light to detect a possible issue.
Do the sites where the problem occurs have something in common? A shared link while others do not?
How is access to the LAN done? Switch? Hub? ...
I use the term 'bagot' to refer to a port that regularly switches from up to down: negotiation issues, cabling problems, etc.
250 frames is a bit light to detect a possible issue.
Do the sites where the problem occurs have something in common? A shared link while others do not?
How is access to the LAN done? Switch? Hub? ...
Hello,
all the sites where the problem is observed are connected via an ADSL VPN managed by Mégalis with a speed of 1Mbit.
Therefore, I do not have access to these routers. :(
Moreover, access to the LAN is done through switches.
I will run another ping test with more packets just in case.
Thanks again for your help :)
all the sites where the problem is observed are connected via an ADSL VPN managed by Mégalis with a speed of 1Mbit.
Therefore, I do not have access to these routers. :(
Moreover, access to the LAN is done through switches.
I will run another ping test with more packets just in case.
Thanks again for your help :)
Hello,
I retested with many more frames (8900) by pinging all the equipment crossed, and it seems that the packet losses are occurring between two devices.
However, I only observe 5 lost packets out of 8900 and a response time of about 57ms.
What do you think?
I retested with many more frames (8900) by pinging all the equipment crossed, and it seems that the packet losses are occurring between two devices.
However, I only observe 5 lost packets out of 8900 and a response time of about 57ms.
What do you think?
Hello,
Even though these 5 losses are not necessarily normal (and you do not specify the size of the packets sent in your post), I do not think this can explain your issues.
Even though these 5 losses are not necessarily normal (and you do not specify the size of the packets sent in your post), I do not think this can explain your issues.
Hello,
okay, I did a test with Wireshark (Ethereal) on the PCs that are having issues.
I found a very large number of error frames
"Checksum: 0x4293 [incorrect, should be 0xc527 (maybe caused by 'TCP checksum offload'?)].
Good Checksum: False
Bad Checksum: True"
From my research, I believe this is a false error, but I'm not sure... I found on a site that we can make this error disappear by changing a network card property on the computer "offload checksum" to "none".
The errors no longer appear, but I don't know if this will fix the issue. What do you think of this technique?
I am waiting for feedback from users.
Thank you
okay, I did a test with Wireshark (Ethereal) on the PCs that are having issues.
I found a very large number of error frames
"Checksum: 0x4293 [incorrect, should be 0xc527 (maybe caused by 'TCP checksum offload'?)].
Good Checksum: False
Bad Checksum: True"
From my research, I believe this is a false error, but I'm not sure... I found on a site that we can make this error disappear by changing a network card property on the computer "offload checksum" to "none".
The errors no longer appear, but I don't know if this will fix the issue. What do you think of this technique?
I am waiting for feedback from users.
Thank you