Wrong! See edit.

Every 250 microseconds the low 8 bits of the millis clock rolls over.
Edit: this started on a false premise right here. Millis gets a tick every 1024 micros, not 1000.

The low 8 bits only count 250 values, the same 6 including FF -never- show up in the low bits of what millis() returns.

So..... in one 1/4 second the low 8 bits is 1 and in a later read end low 8 bits is 254. Any number of 250ms in between will be correct but 254 is the 249 millis it should be plus the 5 skipped values.

254 ms - 1 ms = 253 millis inside of a 250 ms counter, I don't think so!

Worst case, end - start millis() can be +/- 5 ms.

Don't use millis() when being off 5 ms matters.

There is also quite a detailed analysis of the accuracy of millis() here: https://www.best-microcontroller-projects.com/arduino-millis.html
Scroll down to “How does millis() work in Arduino”

GoForSmoke:
Every 250 microseconds the low 8 bits of the millis clock rolls over.

How could it?

GoForSmoke:
The low 8 bits only count 250 values, the same 6 including FF -never- show up in the low bits of what millis() returns.

That is simply false.

uint32_t countLBabove;

void setup() {
  Serial.begin(250000);
}

void loop() {
  static uint32_t lastMillis;
  static uint32_t lastPrint;
  uint32_t topLoop = millis();
  if (lastMillis != topLoop) {
    lastMillis = topLoop;
    if ((topLoop & 0xFF) >= 250) {
      countLBabove++;
    }
  }
  if (topLoop - lastPrint >= 1000) {
    lastPrint = topLoop;
    Serial.print(F("# of values with a low byte above 249 is "));
    Serial.println(countLBabove);
  }
}
# of values with a low byte above 249 is 15
# of values with a low byte above 249 is 35
# of values with a low byte above 249 is 55
# of values with a low byte above 249 is 75
# of values with a low byte above 249 is 95
# of values with a low byte above 249 is 115
# of values with a low byte above 249 is 135
# of values with a low byte above 249 is 155
# of values with a low byte above 249 is 175
# of values with a low byte above 249 is 195
# of values with a low byte above 249 is 210

Thanks for showing that I don't know what YOU mean but it doesn't make me wrong.

I will write a simple sketch now to show what values are skipped but please show me where once millis() returns a value where the low 8 bits == 255.

250,251,252,253 and 254 will show up due to skipped values spaced throughout the 8 low bits.

GoForSmoke:
please show me where once millis() returns a value where the low 8 bits == 255.

I just noticed, that you are moving the goalpost, I won't go that route.
Your initial claim

250 values, the same 6 including FF -never- show up in the low bits of what millis() returns

is false.

I just posted the program that shows exactly that, if counting does not count for you, I added a print.

The missing values maybe exist in the micro second domain, but not in the millis domain.
That all 255 are missing can be caused by the regular skip of two instead of one.

uint32_t countLBabove;

void setup() {
  Serial.begin(250000);
}

void loop() {
  static uint32_t lastMillis;
  static uint32_t lastPrint;
  uint32_t topLoop = millis();
  if (lastMillis != topLoop) {
    lastMillis = topLoop;
    if ((topLoop & 0xFF) >= 250) {
      countLBabove++;
      Serial.println(topLoop, HEX);
    }
  }
  if (topLoop - lastPrint >= 1000) {
    lastPrint = topLoop;
    Serial.print(F("# of values with a low byte above 249 is "));
    Serial.println(countLBabove);
  }
}
FA
FB
FC
FD
FE
1FA
1FB
1FC
1FD
1FE
2FA
2FB
2FC
2FD
2FE
# of values with a low byte above 249 is 15
3FA
3FB
3FC
3FD
3FE
4FA
4FB
4FC
4FD
4FE
5FA
5FB
5FC
5FD
5FE
6FA
6FB
6FC
6FD
6FE
# of values with a low byte above 249 is 35
7FA
7FB
7FC
7FD
7FE
8FA
8FB

I just noticed, that you are moving the goalpost, I won't go that route.
Your initial claim
Quote
250 values, the same 6 including FF -never- show up in the low bits of what millis() returns
is false.

I haven't moved any goalpost, you just miscomprehend what that sentence means.
Try this on for size: 5 of the the skipped values are NOT > 249 so you won't find them testing for > 249.

NONE of your printed results contains a low 8 bits == 0xFF == 255. WHY didn't that wave a flag at you?
Maybe you should get the rest of the context you quoted me from. Show where I stated that all the skipped values are > 249. That is not my idea, it's not what I presented.

These values never show up in the low 8 bits of millis().
42, 85, 127, 170, 213, 255

This sketch shows what low 8 bit values do show up. It doesn't miss a ms, the values that millis() skips never show but please make a sketch showing different. Spend all the time you need.

byte tenperline = 1;
byte previous = 0;
byte now;
byte started = 0;

void setup()
{
  Serial.begin( 115200 );
  delay(10);
  Serial.flush();

  while ((byte) millis() != 0 );

  Serial.print( "\n\nStart\n\n0 " );
}

void loop()
{
  now = (byte) millis();

  if ( started > 0 && now == 0 )
  {
    while ( 1 );
  }

  if ( now > previous )
  {
    started = 1;
    previous = now;
    Serial.print( now, DEC );
    Serial.write( ' ' );

    if ( ++tenperline >= 10 )
    {
      tenperline = 0;
      Serial.println();
    }
  }
}

Start

0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19
20 21 22 23 24 25 26 27 28 29
30 31 32 33 34 35 36 37 38 39
40 41 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60
61 62 63 64 65 66 67 68 69 70
71 72 73 74 75 76 77 78 79 80
81 82 83 84 86 87 88 89 90 91
92 93 94 95 96 97 98 99 100 101
102 103 104 105 106 107 108 109 110 111
112 113 114 115 116 117 118 119 120 121
122 123 124 125 126 128 129 130 131 132
133 134 135 136 137 138 139 140 141 142
143 144 145 146 147 148 149 150 151 152
153 154 155 156 157 158 159 160 161 162
163 164 165 166 167 168 169 171 172 173
174 175 176 177 178 179 180 181 182 183
184 185 186 187 188 189 190 191 192 193
194 195 196 197 198 199 200 201 202 203
204 205 206 207 208 209 210 211 212 214
215 216 217 218 219 220 221 222 223 224
225 226 227 228 229 230 231 232 233 234
235 236 237 238 239 240 241 242 243 244
245 246 247 248 249 250 251 252 253 254

Skipped values of the low 8 bits are
42 ---- 43rd value starting from
85 ---- 86th --------------- +43
127 ---- 128th --------------- +42
170 ---- 171st --------------- +43
213 ---- 214th --------------- +43
255 ---- 256th --------------- +42

It's possible for millis() to be +/- 5 ms off.

GoForSmoke:
It's possible for millis() to be +/- 5 ms off.

That is simply not true.

Whenever the error of millis reaches -.5 ms, it gets adjusted by 1 ms making the error slightly less than +.5 ms.

Your conclusion 'It's possible for millis() to be +/- 5 ms off.' is not valid.

Whandall:
That is simply not true.

Whenever the error of millis reaches -.5 ms, it gets adjusted by an additional 1 ms making the error slightly below +.5 ms.

Your conclusion 'It's possible for millis() to be +/- 5 ms off.' is not valid.

So the time is right to +/- .5 whatever value you do get?

Skipped: 42, 85, 127, 170, 213, 255

Then end time 240 - start time 40 can worse case be 240.5 - 39.5... 1 ms off?

GoForSmoke:
So the time is right to +/- .5 whatever value you do get?

Yes.

That can accumulate (by picking extrem values for start and end) to an error of about +/-1 ms total.

The + or - when working with 2 times.... 41 will always be +, 43 always -, subtraction without adjustment gets 2.

41 will always be +, 86 always -, 214 always -.

I get like 20 worst cases and 20 best cases out of 62,500 possible.

See the 1st post, top 2 lines now.

So what?

There is a documented possible error of +/-1 ms with millis timing.

Look again at the first post speedy.

I adjusted my post likewise.

Back when I was first wrong on this (and yet forgot again) I was using 8 bit counters for millis timing debounce. When the pin-stable debounce interval got to 2 ms I ran into problems and started looking.

I started using 16 bit micros to debounce sometime since.

It's been a bad winter and now this.