Alexander, I was testing a nano-second and I'm starting to like it.
Can you also compile agent for windows for testing? I want to hurry up to test it.

Windows agents is available in svn://svn.zabbix.com/branches/dev/zbxnext-457 branch.

Bug founded for windows agent. Windows not like nanoseconds IMHO
i attached text file for better view

Can we add some dummy nanoseconds if the clock+ns pairs turn out to be identical? In the attachment above, if we are about to send several items with clock=1280483969 and ns=711000000, can we change the second ns to 711000001, etc.? We will not get real nanosecond precision anyway.

Good point!

FreeBSD8.0 also not get REAL nanosecond (maybe is normally - i don't now).
Zabbix server calculated only MICROsecond !!!
If i send with zabbix_sender (not this 457) simple data server write to db 'ns':
147491000
186395000
166976000
186594000
395702000
995246000
474586000
Last three digits - always ZERO.
It's just simply information - not bug.

Note that not all platforms support nanoseconds. It is a platform specific feature.

Added support nanoseconds for BSD and Linux platforms. Windows later.

r13724 - added support of nanoseconds under Windows.

Tested. Now it seems everything is normal - windows agent generates the 'ns' of 9 digits. FreeBSD 8.0 also - 9 digits.
But he wanted to draw attention - the old agent (not this ZBXNEXT-457) sends the data without the 'ns' and in this case, the zabbix server does not compute the 'ns' and always write ZERO into database 'ns' value. End problem in result as in my previous example.
I think need to support compatibility with older agents in this regard.

Added support of nanoseconds in ver. pre2.0 r13742.

Just for record: available in first alpha 1.9.0

Just an update after ... 11 years

Now zabbix server generates nanoseconds consequently with step just 1, not 9 digits as before.
So, when sending data by zabbix_sender with timestamps and it's the same for a few values of an item key, nanoseconds will be 1 byte values "0" ..... "N".

If send the same data again, it will generate SQL errors, which is expected in zabbix 6.0 due to primary keys (itemid-clock-ns):

227944:20230228:162907.374 [Z3008] query failed due to primary key constraint: [1062] Duplicate entry '42741-1677593860-1' for key 'history_str.PRIMARY'
227944:20230228:162907.374 skipped 1 duplicates
227944:20230228:162907.374 [Z3008] query failed due to primary key constraint: [1062] Duplicate entry '42741-1677593860-2' for key 'history_str.PRIMARY'
227944:20230228:162907.374 skipped 1 duplicates
227944:20230228:162907.375 [Z3008] query failed due to primary key constraint: [1062] Duplicate entry '42741-1677593860-3' for key 'history_str.PRIMARY'
227944:20230228:162907.375 skipped 1 duplicates
227944:20230228:162907.375 [Z3008] query failed due to primary key constraint: [1062] Duplicate entry '42741-1677593860-4' for key 'history_str.PRIMARY'
227944:20230228:162907.375 skipped 1 duplicates

<sasha> This is because of the unique primary keys added in scope of ZBXNEXT-6921. Such history values will be re-saved with an incremented "ns" field value.

<zalex_ua> That's right and that's ok. I left the comment as just a note, it might help in future. I had a case where such SQL errors have been logged on a production installation, so we figured out that the same data with timestamps has been sent a few times by mistake.