I also want this function, but now the session timestamp can not show millisecond.

Sorry for the late reply. Because I've been sick recently.

I will improve this in the next bugfix version WindTerm_2.3.1, which is expected to be released this week. Please stay tuned, thank you.

@darkhandz
WindTerm already supports displaying the millisecond part of the timestamp. Please open the session's Session Setting dialog and change Window - Time Format from [HH:mm:ss] to [HH:mm:ss.zzz], then restart the session and you'll get what you want. 😄

@kingToolbox
I have try the millisecond, it's really useful for me, but I also found that it's value always ends with an odd number, is it cause by a timer? Could it be more accurate in the future? (maybe a few people care about this, maybe it's not worth it in terms of performance, maybe you have other more urgent work to do, etc.)

Like the screenshot below: (green timestamp column is output by my embeded system, which is not too accurate.)

Hope you will get well soon.

Thank you very much for your concern, I'm feeling much better now, at least I can continue to develop WindTerm. 😄

I have to say you are very observant. The precision of the timestamp was indeed adjusted to 8ms by me. This is because the variable used to store timestamps is a 32-bit unsigned integer with the maximum value of 4294967296. If the timestamp precision is 1ms, it will overflow after 4294967296 / (24 * 60 * 60 * 1000) = 49.71 days. Since WindTerm is very stable, 49.71 days are definitely not enough. 😄 So I was going to adjust the precision to 10ms. But you know that shift is faster than division, I ended up shifting the timestamp right by 3 bits (equivalent to dividing by 8). In this way, WindTerm can be used continuously for 49.71 * 8 = 397.68 days without overflow, which can meet almost all usage needs.

The reason for not using 64-bit integers is to save memory, otherwise it would take 8MB to store timestamps per million lines, which is obviously unrealistic.

Of course, because WindTerm uses a variety of memory-saving designs, it usually only needs to consume 0.1MB of memory per million lines. Using 32-bit unsigned integer is also one of the methods.

So high-precision timestamps require more memory. If you can accept this, I can provide this feature in the next release.

However I must point out that this precision does not have much practical significance. One is that the received data itself already has network latency, and the other is that this time is only local time, not actual server time. This is also a very important reason why I did not provide high precision timestamps. (Subsequent versions will support getting server time instead of local time as timestamps.)

Thank you for your detailed explanation.

I know that most people use SSH sessions on a terminal, but a few people debug RTOS using serial ports, and sometimes they may concerned about milliseconds difference.

So, if you can add this feature, I will be happy, but if this requires lots of effort or cause bugs, and I will understand it is not worthy. 😁

No, no, not at all, it is just a little manual job. It is a wonderful thing for a tool maker to be able to make a feature that is useful to the user. 😄 This is also the value of the existence of WindTerm, which is to make everyone's work easier.

I will implement this feature in either WindTerm_2.4.0_Prerelease_1 or WindTerm_2.4.0_Prerelease_2 and will update here if there is any progress. Please stay tuned, thank you.

I am happy to inform you that WindTerm_2.3.1 has been released and this issue has been fixed. Please download and check it. If there are still bugs, please let me know, thank you.

@darkhandz
The precision of the timestamp has been improved to 1ms too, but the high precision is only available if you set the timestamp to display milliseconds. 😄

This issue has been solved and will be closed. Welcome to continue submitting new feature requests and bugs, thank you.