_delay_ms() not providing a proper delay

https://www.nongnu.org/avr-libc/user-manual/group__util__delay.html#gad22e7a36b80e2f917324dc43a425e9d3

F_CPU can be set as a compiler parameter (-D) or as a definition 
(#define) in your source code. If it is in source code, then it must be 
placed above the #include statement that load the util/delay.h file.

The value of F_CPU must match the real clock frequency of the CPU, but 
it cannot be used to configure the CPU. The CPU derives its clock from 
an external crystal or resonator which should oscillate at 16 MHz. If 
the fuse CLKDIV8 is set, then the initial CPU clock is 1/8 of the 16 
MHz. On Arduino modules, this fuse should normally be off. Check that.

You software can modify the clock divider by writing to the CLKPRE 
register. You can divide the 16 MHz by 1 .. 256.

Something is wired in your case because you say that the time is 1/4 of 
the expected one. So the CPU seems to run at 64 MHz. Needless to say 
that this is technically impossible. So the only thing I could imagine 
is that your F_CPU is not properly set, although you say that it is.

Echotwozero wrote:
> The function _delay_ms(1000) does not actually generate
> a delay of 1000 ms. It is atleast 4 times faster.

First answer was korrekt: The maximal possible delay is 262.14 ms / 
F_CPU in MHz

No!

Avr-libc says it is possible to define delays up to 6.5535 seconds 
(independent from CPU frequency).

>void _delay_ms   (   double    __ms  )

>Perform a delay of __ms milliseconds, using _delay_loop_2().

>The macro F_CPU is supposed to be defined to a constant defining the CPU clock 
frequency (in Hertz).

>The maximal possible delay is 262.14 ms / F_CPU in MHz.

>When the user request delay which exceed the maximum possible one, _delay_ms() 
provides a decreased resolution functionality. In this mode _delay_ms() will work 
with a resolution of 1/10 ms, providing delays up to 6.5535 seconds (independent 
from CPU frequency). The user will not be informed about decreased resolution.

Lutz wrote:
> First answer was korrekt: The maximal possible delay is 262.14 ms /
> F_CPU in MHz

How does this fit to the observation of 250ms faster at 16 Mhz?

262.14 ms / 16 = 16.4 ms

Read the paragraph below that in the documentation. As Gerhard wrote, 
much longer delays are possible but then the resolution is only 1/10 
seconds which is not a problem in this case. Most people even did not 
notice that the delay function can be called with a floating point 
parameter to delay fractions a milliseconds.

Echotwozero wrote:
> ATMega2560 controller

Is that a self-made device? Crystals may oscillate with a higher 
frequency if the capacitor are missing or much too small.

Please check also this:
Could it be possible, that your Core currently running on internal osc 
with 8MHz?
This would decribe the the Quarter delay:
1. 8MHz instead of 16MHz
2. Clock Divider of 8 is set

Is 8 MHz the quarter of 16 MHz?

There is a CLKO pin (PE7). If you set the fuse CKOUT, this pin will 
carry the system clock and you can measure the actual frequency.

NickNack wrote:
> Could it be possible, that your Core currently running on internal osc
> with 8MHz?
> This would decribe the the Quarter delay:
> 1. 8MHz instead of 16MHz
> 2. Clock Divider of 8 is set

stefanus wrote:
> Is 8 MHz the quarter of 16 MHz?

Ah, I got it (Facepalm).

16 MHz / 8 = 2 MHz

8 MHz ist 4x faster than 2 MHz.