Network Time Protocol (NTP) on Ultibo Pi

[AlanTheBeast]

In case anyone was wondering.

In the basic Ultibo package, depending on what units are selected, NTP¹ is automatically activated; for example if Webstatus is included, then it is on.  (Not sure what other units might invoke it - but if they include the Services unit, it's a good bet).  Thus if you use "Now" or "ClockGetTime" you're using UTC time (Assuming you're connected to the internet, of course).  (There are also some time zone functions in "there" somewhere which I don't use).
(It can be set off using a initunit:  NTP_AUTOSTART := false; statement ).

I tested it against a GPS 1 PPS output² using the interrupt and found a large error (700ms if memory serves).  Repeat tests had random errors in [0..999] ms.

I mentioned this on the Ultibo forum.  It turns out that in versions of Ultibo before 2.5.105 that Ultibo weren't confident in the accuracy of their NTP implementation and so rounded (truncated) off to 1s.  (No clue why - Ultibo folks do a fine job with everything).

Knowing that I was doing a GPS nav project and a bit obsessed with time accuracy³, Ultibo asked me to test v. the GPS if they let the NTP go full accuracy. 

Of course!

It was clear from the very first test that it works very well.  I'm now wrapping up other tests on various servers just to confirm some behaviours, but if you need NTP on Ultibo Rasp Pi, fear not - it works very well with typical ±10 ms level error v. UTC out of the gate.  (Though it may start out higher (20ms) and take a while to settle).  Along the way learned some things I didn't expect and tripped over my own assumptions and biases several times.  What else is new?  IAC, Ultibo's voice, big G, is quite patient with me and I got some great suggestions from others on that forum.

(For the curious I use the 1 PPS off of the GPS receiver and timestamp with ClockGetTotal⁴ in an interrupt and then wait for the 1 Hz nav message which includes ms since the beginning of the week.  Convert the GPS time to whatever  number of 100ns ticks since 1601-01-01 is called⁵ (plus time since the interrupt) to compare against NTP in the Pi.

My test is accurate to about 10 µs on the Pi 4 - way sharper than NTP.  (I'd need an oscilloscope to characterize the test time error better than that....)).
____________________________________________________
1. https://www.eecis.udel.edu/~mills/database/papers/history/history.pdf
2. About ±30 to ±50 ns v. UTC top of second.
3. I'm not much concerned about UTC but rather events at higher rates (25 and 1000 Hz).
4. ClockGetTotal in the Pi 4 is 54,000,000 ticks/s - ~18.5 ns.  GetTickCount64?  Hardly knew ye⁶.
5. Some standard that MS use and that Ultibo uses for file times.  Why MS couldn't be happy with 1 µs is one of those mysteries ...
6. Don't worry - still very useful.

[AlanTheBeast]

A graph of Ultibo-NTP v. GPS over a 1 hour period.  YMMV.

[ccrause]

My test is accurate to about 10 µs on the Pi 4 - way sharper than NTP.  (I'd need an oscilloscope to characterize the test time error better than that....)).

I'm interrested in your measurement methodology - are you reading the GPS pulses with a pin on the PI?  Is your code called via pin change interrupt, or running in a busy loop?

Also, is both the GPS monitoring code and the NTP/internal timer code running on the same core?

[MarkMLl]

I'm interrested in your measurement methodology - are you reading the GPS pulses with a pin on the PI?  Is your code called via pin change interrupt, or running in a busy loop?

And if using a GPIO pin, what API? The obvious questions are (a) how much jitter is being seen and (b) the overall drift.

My experience is that there is a slowly-varying systematic error between the various satellite constellations, a much larger variation between that and a PPS signal, and forget anything to do with a radiocode clock using consumer electronics.

I don't want to say too much more about what I was doing there, but it involved a decent logic analyser attached to (among other things) either a PC or an RPi dedicated to generating a PPS signal. Link below is relevant.

https://www.eevblog.com/forum/metrology/pps-output-using-linux-on-a-pc/msg3558208/#msg3558208

MarkMLl

[AlanTheBeast]

My test is accurate to about 10 µs on the Pi 4 - way sharper than NTP.  (I'd need an oscilloscope to characterize the test time error better than that....)).

I'm interrested in your measurement methodology - are you reading the GPS pulses with a pin on the PI?  Is your code called via pin change interrupt, or running in a busy loop?

Also, is both the GPS monitoring code and the NTP/internal timer code running on the same core?

0. RTL:  Ultibo Pascal RTL (32 bit presently, 64 bit v. imminent (I'm told)).

1. Pi 4.

2. GPS

• UART @ 921600 bps (not that it matters much - if it were at the default 38400 bps it would work just as well)
  
• 1 PPS pulse programmed (by setting to the GPS via UART) for TOS on rising edge.
  
• The GPS is "told" to make measurements at 1 Hz.
  
• The GPS is told to send the NAV-PVT message at the rate of 1 per measurement.  (in this case 1 Hz)
  
  • NAV-PVT contains, amongst many things, the number of ms since the beginning of the GPS week (00:00:00.000000000 of Sunday morning, UTC).
    

• The GPS is told to send its LeapSecond value since the inception of GPS (1980 ish).  Current Leap second is 18.
  

GPS manufacturer (ublox) states the 1 PPS error as ±30 ns RMS, ±60 ns (99%)

Antenna (active) is on the roof with a good view of the sky.  At 1 Hz, the GPS tracks about 30 satellites (GPS, Galileo, Beidou and *&^%&*^%).  For UTC, the time is off of the US GPS system - but the over determined position is from all sources (and SBAS) which helps the time be more accurate (ns level - not very germane here.  I've also programmed the GPS for a 76ns delay for the RF cable (15.24m), but again, not really germane to these results).

3. GPIO
Interrupt programmed as follows.  This was with a lot of help from big G at Ultibo.   It's a FIQ (fastest) and is the fastest possible interrupt for users of the RTL.
There are some h/w details I don't fully understand, but, at least since the Pi4, interrupts can be finely "caught" on a pin-by-pin basis and dispatched to an interrupt handler.  That is handled by the RTL.  I've used this interrupt at up to 2000 Hz with no issues (but it's 1 Hz for the NTP checking program).

Code: Pascal  [Select][+][-]

1. Procedure GPS_Pulse_Interrupt (P:pointer; PI, TI:Longword);  // H/W interrupt trapped by GPIO unit with callback to here.
2. BEGIN
3.    GPS_PPS_InterruptTime := ClockGetTotal;  // On Pi4: 1/54000000s resolution
4.    Inc(GPS_PPS_InterruptCount);
5. END;
6.  
7. Procedure Config_PPS_Interrupt;
8. CONST
9.      PPS_intline = GPIO_PIN_4;
10. BEGIN
11.   If Interrupt_PPS = nil then
12.     begin
13.       GPS_PPS_InterruptCount := 0;   //this is an int64
14.       Interrupt_PPS := GPIODeviceFindByDescription('BCM2838 GPIO');
15.       if Interrupt_PPS = nil then begin ConsoleWindowWriteln(Con1, 'Set up GPS pulse interrupt - received NIL pointer'); exit end;
16.       GPS_Int_Result := GPIODeviceInputEvent(Interrupt_PPS, PPS_intline,
17.                         GPIO_TRIGGER_RISING, GPIO_EVENT_FLAG_REPEAT or GPIO_EVENT_FLAG_INTERRUPT,
18.                         INFINITE, @GPS_Pulse_Interrupt, nil);
19.     end;
20. END;
21.  

Method:
1. Notice in the interrupt that there is "GPS_PPS_InterruptTime".  This tells me the time-since-start-of-the-computer of the top of the UTC second to sub µs level.  Not sure "how" sub µsec as I don't have a scope to set up measurements.
.. this is number of ticks since the computer started.
.. each tick has a resolution of 1/54,000,000s.  (about 18.5 ns).

What "time"?

A. System time: When NTP is active on the computer the computer system time is set by the NTP function in the Services unit.  Thus, "Now" and "ClockGetTime" return the system time set by NTP.  This program doesn't need to "do" anything with respect to that.  (But does have a function to load a list of NTP sources and use them via a client function within the Services package).  Or simply set the default NTP to a particular service and re-start.

B: GPSTime.  Pretty trivial to take the GPS time and set the system time and that can be done in a few lines of code.  Of course if NTP is running, when it polls and updates the system time there is no "notice given".  So for this program GPS time is always kept separate from system time so that comparison can be made.

Just using a UART one can set their system time to well less than 1 second away from UTC.  Depending on the maker of the device, the offset from top-of-second (TOS) will vary.  To know when that "was" the 1 PPS pulse can be used to move the result into the µsec (or even 100 nsec) realm.  An interrupt is the best way to do this but more complicated.  OTOH, if one wanted to "watch" the pulse once per 5 minutes or 1 per hour, the end result would be very sharp.  Some smart programming would have the "watch" period begin close to TOS.  Note that there's also the possibility to characterize the drift rate of the computer's clock and that in turn can be used to decide on the polling rate.  Once per day would suffice for many uses.

2. Elsewhere in the code is the stuff that reads in messages from the GPS receiver, identifies the message and passes to the correct decoder.

3. One of those decoders is the NAV-PVT decode thread.   It has various "states" and begins with initialization states which (amongst other things):
- on receipt of the first valid nav message (state -1).
.... sends a request to the GPS to send the Leap Second message 
.... waits in the next state (-2) (could take 2 or 3 seconds) for the GPS  to reach at least a 2D fix _and_
,,,,,for the LeapSecondValid flag (set by the LeapSecond decoder thread).
.... computes the beginning of the week in the RTL's time frame reference, to wit:    100ns ticks since 1601-01-01.    MINUS: the GPS LeapSecond.

THIS IS THE KEY:  That value represents exactly the beginning of the GPS week in the RTL's time system of 100ns ticks since 1601-01-01.

NOTICE:
a) The "real time" clock of the system is 1/10,000,000s (100ns) ticks origin 0 at 1601-01-01::00:00:00.000...
b) The "measurement" ticks are 1/54,000,000s (~18.5ns) since the computer started (h/w level tick counter of the Pi 4).

4. Meanwhile, the 1 PPS (from GPS PPS pin) interrupt "stamps" the Pi's H/W "tick counts" into GPS_PPS_InterruptTime.  That is precisely when it happened to a resolution of ~18.5ns and to an accuracy somewhat better than 1 µsec.
The GPS NAV message also contains an error estimate for the time.  This is usually around 35ns or so.  I don't know if this applies to the 1PPS or not, but it is negligible for these tests.  (The doc says: "Time accuracy estimate (UTC)" w/o further elaboration).

5. At 1 Hz, the GPS message comes in about 30 - 45 ms after the interrupt.  This varies for too many reasons to get into, but it's in that range.

6. Once the message is in, and the ToWms value extracted from the message ("when the interrupt happened"), then the number of 100ns ticks since the beginning of 1601-01-01 can be computed (note, at 1 Hz, the ToWMS portion of the nav time is always exactly 0 as it represents "top of the second".  The message arrives 30 - 45ms later, however).

Point of compare
Sample both the RTL "Now" [ClockGetTime] (which is set to 100ns ticks since 1601-01-01 - and with NTP running represents NTP time(UTC)) and the [ClockGetTotal] (ticks since "start of computer @ 1/54,000,000s per tick).  It doesn't matter "when" we sample these values, but they must be close together.  Since pre-emption is possible, we'll do this inside a 2 1 µsec gate.   (Per Rt results it's usually around 35 and has never gone past 84 ticks or ~1.5 µs in a passed gate.   (It's tempting to narrow the gate to 1 µs and I'll try that today and add a counter for times the loop has to repeat.  Update: the 1 µs gate has been running for an hour week.  It had to repeat at least once a few times until I removed the checking code.  Theoretically improves the result by some tiny amount (½ µs?  Not sure.)).

While the gate (Repeat .. Until) is 1 µs "wide", the time between NOWCGT := ... and NOWCGTot is much smaller - and the "real" time difference beteen the 2 at the "point of compare" is less than ½ µs.  (And when Ultibo finally releases as 64 bit, probably less than ¼ µs).
(Also removed a "Rt := NowCGTot - Rt" before the Until test, saves about 5 ARM instructions.  Will improve moreso with 64 bit).

Code: Pascal  [Select][+][-]

1.                      Repeat                             //in case preempted between samples.
2.                          Rt:= ClockGetTotal;            //Gate ref: 18.5 ns resolution
3.                          NowCGT   := ClockGetTime;      //sample (100 ns resolution)  <<<< Is = NTP time but in the 100ns ticks since 1601-01-01 format
4.                          NowCGTot := ClockGetTotal;     //sample ( 18.5 ns resolution)
5.                      Until (NowCGTot - Rt) < 54;       //gate for close sampling : 1 µsec window.

The above can be improved by disabling interrupts but care needs to be taken to ensure the system time has been set to some "real" value before the call to ClockGetTime (some deeper issue with potential deadlock if the time has not yet been set).  I take care to do so with the GPS time before I start the thread that contains this code.  So, with that caveat in mind, replace the above section with:

Code: Pascal  [Select][+][-]

1.                      Mask     := SaveIRQFIQ;        //Disable IRQ/FIQ and return the previous state
2.                      NowCGT   := ClockGetTime;   //sample (100 ns resolution)  <<<< Is = NTP time but in the 100ns ticks since 1601-01-01 format
3.                      NowCGTot := ClockGetTotal;   //sample ( 18.5 ns resolution)
4.                      RestoreIRQFIQ (Mask);          //Restore the previous state of IRQ/FIQ

Where Mask is a variable of type TIRQFIQMask .  This is, to me, more satisfactory as driving the machine goes than the "gate" Repeat/Until loop above.  But the prior works quite well and there is little time cost to it.  The latter is slightly less friendly, but as long as the time is correctly set earlier in the run, then it is no issue.   Further of course, the difference in time between the two samples is guaranteed to be very close to the bottom end of a µsec rather than probably close to the bottom of a µs.  I'd venture that in 64 bit code it would be sub µsec which will be very useful on other projects.  Is this "bare metal"?  No. But the coating is very thin....

So, onward ....

.. compute the exact time of the interrupt since 1601-01-01 in 100 ns ticks. ToWms is "Top of week milliseconds"  -- ms since sun morning UTC.  X 10000 = 100 ns ticks.

Code: Pascal  [Select][+][-]

1. Function GPSTimeInCGT (ToWms:longword):int64; inline;
2. BEGIN
3.      Result := WeekTickRef + int64(Towms) * 10000;
4. END;
5.  

Then add the number of 100ns ticks between the interrupt and the moment of comparison ("sampling "instant"") - and convert from 1/54,000,000 (~18.5ns) ticks to 1/10,000,000 (100ns) ticks:

Code: Pascal  [Select][+][-]

1.                      NowGPS := GPSTimeInCGT(ToWms) + ((NowCGTot - GPS_PPS_InterruptTime) * 10 ) div 54;
2.  

Then we can compute the error between the NTP and GPS as simply:

Code: Pascal  [Select][+][-]

1.                      dCG := NowGPS - NowCGT;
2.  

Where dCG is in 100 ns tick units.  +result == NTP "lateness".

In summary it comes down to three "chunks" of time.

-- A really big chunk of 100ns ticks since 1601-01-01 to the beginning of the GPS week - computed once per program execution (and updated if ToWMS < Previous_ToWMs) by adding 7 days of 100ns ticks to the WeekTickRef value.  This happens once per week.

-- a chunk of 100ns ticks since top-of-the GPS week until the instant of the interrupt.

-- a tiny chunk of 100ns ticks since the interrupt until instant of sampling the "Now" (in NTP 100ns ticks) v the GPS (in 100ns ticks).

As to core run location.
The NTP tests use some of my NAV code which is divided:

..serial GPS input thread: Core 0.
..message dispatcher: Core 1.     ___ Frankly the message dispatcher and serial input can be on the same core with no issues at all.
..decoders: Core 2 ____ these could also run on the same core as the above.

..EXCEPT NAV-PVT messages: thread is on Core 3.  it's a big (92 byte) message (as far as GPS goes) with about 35 parameters (I use about a dozen) and in the Nav app is at 25 messages per second.  A lot of stuff happens with it.

..NTP code: no idea what core it's on.  The Ultibo thread thrower is pretty well balanced in my experience.  NTP does not "cycle" often.  It's a slow machine that goes to the web (typically) once every 5 minutes.  The process is not all that intensive.

Edit: typos, clarification and 1 PPS error range per manuf.
Edit: 1 PPS error
Edit: added stuff about core/NTP.
Edit: 2022-09-03 - added some details about time references (clarification) and fixed some typos.
Edit: 2022-09-05 - more massage...
Edit: 2022-09-07 - finicky detail around the sampling gate.
Edit: 2022-09-09 - alternate sampling scheme that avoids using a gate

[AlanTheBeast]

I'm interrested in your measurement methodology - are you reading the GPS pulses with a pin on the PI?  Is your code called via pin change interrupt, or running in a busy loop?

And if using a GPIO pin, what API? The obvious questions are (a) how much jitter is being seen and (b) the overall drift.

- Don't need no stinkin' API.   See my reply to M. Crause for specfics.
a) Which jitter?
interrupt?  Past experiments (extensive sampling) suggest sub 18.5ns (99.99% - literally - it's actually a test I want to run again - I suspect it's closer to 99.999% sub 18.5ns)
And, of course, for these tests if it were up in the several µs it would still be fine.

b)
i: Drift of UTC is taken as 0.  On a day to day / week to week basis it oscillates at the 1 or 2 ns level.  An anomaly event of ±3 ns in 2016 had the community in an uproar for a while.
ii: The drift of the Pi (well my Pi4) is about 10 .. 12 PPM.  And doesn't matter at all for these tests - though as the graph above shows, it's consistent.
Get my drift?  Any others?

(Well, of course every few years they throw in a leap second to account for the rotation rate of the rock, but that's waaaaaaaaaayyyyyyyy outside this test - but accounted for at the gross scale of seconds in the reference timemark.  (No choice).

My experience is that there is a slowly-varying systematic error between the various satellite constellations, a much larger variation between that and a PPS signal, and forget anything to do with a radiocode clock using consumer electronics.

Not esp. relevant as I'm using one constellation for the 1 PPS (US GPS aligned to the US Navy observatory's definition of UTC).  The rate of drift of their UTC mark is:

So system UTC error:  ±2 ns
GPS receiver PPS error: ±30 ns RMS, ±60 ns (99%) (per manufacturer data sheet).

So: irrelevant as my test "truth" is up in the 1 .. 10 µsec range to test NTP which is reliably in the ±20 ms range - most of the time...

[MarkMLl]

- Don't need no stinkin' API.   See my reply to M. Crause for specfics.

Good point: you're effectively bare-metal. I'd caution anybody getting here via Google to be extremely careful with the Raspberry Pi (or for that matter PC) GPIO APIs, which are either imprecise, non-portable, or both.

a) Which jitter?
interrupt?  Past experiments (extensive sampling) suggest sub 18.5ns (99.99% - literally - it's actually a test I want to run again - I suspect it's closer to 99.999% sub 18.5ns)
And, of course, for these tests if it were up in the several µs it would still be fine.

Sub-5nSec in my case, comparing the various GNSS constellations using multiple receivers. However at present I don't want to put a time constraint on that, in all probability there's some fairly major relative shifts due either to different underlying maths or to different explicit corrections.

Not esp. relevant as I'm using one constellation for the 1 PPS (US GPS aligned to the US Navy observatory's definition of UTC).  The rate of drift of their UTC mark is:

Noting your other comments, but I thought you were in the Commonwealth so WTF does the US have to do with UTC?

I /do/ have a problem here, since in the UK we don't have an official high-precision clock other than the phase of 60kHz MSF... unless one can afford to pay Big Money to get a fibre from NPL.

MarkMLl

[AlanTheBeast]

a) Which jitter?
interrupt?  Past experiments (extensive sampling) suggest sub 18.5ns (99.99% - literally - it's actually a test I want to run again - I suspect it's closer to 99.999% sub 18.5ns)
And, of course, for these tests if it were up in the several µs it would still be fine.

Sub-5nSec in my case, comparing the various GNSS constellations using multiple receivers. However at present I don't want to put a time constraint on that, in all probability there's some fairly major relative shifts due either to different underlying maths or to different explicit corrections.

Absent the eqt. my former employer had for us, I'm delighted I can measure anything this accurately for a few bucks and a few lines of code.

In the end this test is in 4 time realms:

- ns level    - resolution of finest available timer (~18.5 ns)
- µsec level - resolution accuracy of finest available "truth" with the equipment on hand (1..10µs conservatively - I'm pretty sure it's sub µs).
- ms level.  - the expected accuracy of a web delivered NTP time (±10ms generally, but can be worse, can be better ... even over long distances).
- centuries  - it still irks me that, for this test, I had to resort to a time 0 when Shakespeare was still working on Hamlet.

Quote author=William Shakespeare date=1601-01-01

I'll watch to-night.
Upon the platform, 'twixt eleven and twelve
I'll visit you.
/Hamlet

Not esp. relevant as I'm using one constellation for the 1 PPS (US GPS aligned to the US Navy observatory's definition of UTC).  The rate of drift of their UTC mark is:

Noting your other comments, but I thought you were in the Commonwealth so WTF does the US have to do with UTC?

Their GPS... their time mark, kind of hard to dance away from it.

I /do/ have a problem here, since in the UK we don't have an official high-precision clock other than the phase of 60kHz MSF... unless one can afford to pay Big Money to get a fibre from NPL.

Brit inferiority complex would be quaint if it weren't so frequent. 
At least you didn't bemoan GMT's loss of relevance.  There's that.

I'd say have a labour free labour day weekend, but I guess that's not British either ...

[MarkMLl]

Their GPS... their time mark, kind of hard to dance away from it.

But /not/ their UTC.

Brit inferiority complex would be quaint if it weren't so frequent. 
At least you didn't bemoan GMT's loss of relevance.  There's that.

If you don't mind, we /never/ refer to ourselves as Brits and find it vaguely offensive. And I can assure you that there are people with far worse NIH syndrome than ours.

The bottom line is that in any jurisdiction it's highly desirable to be able to adhere to the standards that that jurisdiction implements. In the EU a good timing datum can be extracted from Galileo, but the UK's leaving the EU was so ill-considered (and, in my opinion, ill-advised) that it is still unclear where our metrology stands.

I agree that the loss of GMT is unfortunate, after all we invented that stuff. But in any sane World the Prime Meridian would run through Florence.

MarkMLl

[ccrause]

Thank you for the detail Alan.

[AlanTheBeast]

Their GPS... their time mark, kind of hard to dance away from it.

But /not/ their UTC.

Brit inferiority complex would be quaint if it weren't so frequent. 
At least you didn't bemoan GMT's loss of relevance.  There's that.

If you don't mind, we /never/ refer to ourselves as Brits and find it vaguely offensive. And I can assure you that there are people with far worse NIH syndrome than ours.

The bottom line is that in any jurisdiction it's highly desirable to be able to adhere to the standards that that jurisdiction implements. In the EU a good timing datum can be extracted from Galileo, but the UK's leaving the EU was so ill-considered (and, in my opinion, ill-advised) that it is still unclear where our metrology stands.

I agree that the loss of GMT is unfortunate, after all we invented that stuff. But in any sane World the Prime Meridian would run through Florence.

MarkMLl

1. /You/ don't refer to yourself as Brits.  What the rest of us label you is not much in your control.  Engage stiff upper lip, wot.
2. UTC is an international standard. The US are part of that standards body. (bodies?).
    Heck, they legally adopted the metric system in 1895 ish, though it's hard to tell.
3. Last time I "ran through Florence" her husband came after me with a shotgun.

[AlanTheBeast]

Thank you for the detail Alan.

You're very welcome.  I'll probably tidy that post up a little over time. 

[beria]

If you don't mind, we /never/ refer to ourselves as Brits and find it vaguely offensive. And I can assure you that there are people with far worse NIH syndrome than ours.

Sorry to intrude, but what do you call yourself?

[MarkMLl]

If you don't mind, we /never/ refer to ourselves as Brits and find it vaguely offensive. And I can assure you that there are people with far worse NIH syndrome than ours.

Sorry to intrude, but what do you call yourself?

Well, the country is the United Kingdom of Great Britain and Northern Ireland, and while we might be formally described as UK citizens that's hardly ever used informally even in discussion of documents such as "British Passport" or "UK passport" (never "UKish").

"British" is common, but equally common are "English", Scottish" and "Welsh"... these are a combination of toponym and ethnicity. Plus of course "Northern-Irish Catholic" and "Loyalist": that one's complex and unpleasant. Plus the extremely informal and unofficial "Scouse", "Geordie", "Kernow" and so on.

So as somebody born in Wales of mostly Welsh ethnicity, I'm a British Welshman or (loosely) a Welsh Briton. Unfortunately, I can no longer claim to be European except by inclination.

But "Brit" is quite simply never used.

MarkMLl

[ccrause]

If you don't mind, we /never/ refer to ourselves as Brits and find it vaguely offensive. And I can assure you that there are people with far worse NIH syndrome than ours.

Sorry to intrude, but what do you call yourself?

Well, the country is the United Kingdom of Great Britain and Northern Ireland, and while we might be formally described as UK citizens that's hardly ever used informally even in discussion of documents such as "British Passport" or "UK passport" (never "UKish").

"British" is common, but equally common are "English", Scottish" and "Welsh"... these are a combination of toponym and ethnicity. Plus of course "Northern-Irish Catholic" and "Loyalist": that one's complex and unpleasant. Plus the extremely informal and unofficial "Scouse", "Geordie", "Kernow" and so on.

So as somebody born in Wales of mostly Welsh ethnicity, I'm a British Welshman or (loosely) a Welsh Briton. Unfortunately, I can no longer claim to be European except by inclination.

But "Brit" is quite simply never used.

MarkMLl

Some of this complexity can be illustrated by a Venn diagram, see e.g. this diagram.