This could have been figured out just by looking up what actual hardware is in an Amiga, or even any typical 16-bit computer. 400-ish nanosecond latency is slooooooow for this kind of machine. Even the IBM PC used DRAMs faster than 300ns (it was either 250 or 200, I forget which). The actual memory used in yer typical Amiga (or ST, even) was 150ns. Sometimes 120ns when that became cheaper, because technically the 150ns stuff was being somewhat overdriven (especially in the Atari) - the actual memory cycle in an Amiga is not 280ns, but 140ns, because for every access the 7.1MHz 68000 makes (on a 4-clock cycle), the video also makes one (and similar for the 8MHz ST).
[EDIT - OK, I got that a bit backwards; a full 68K cycle is in fact 560ns, with two actual memory access slots of 280ns each - usually one to CPU, one to DMA (covering video, audio, blitter, disk...) - themselves composed of two 140ns clock ticks. It's the ticks that are crucial, as the memory has to be able to respond to an issued RW request within ~roughly~ 140ns (thus, you can "push" decent 150ns parts)... every 280ns, continually. It's easy to get confused by it, I admit; getting it straight requires an understanding of how memory works, how the timings are designated, and how the computer architecture is set up]
(This is assuming the default 16-colour 320-pixel mode, or 4-colour 640-pixel, which gives the best balance of CPU performance vs image quality; the majority of 68000 instructions are aligned to a 4-clock rhythm, and a memory access is a minimum of 4 clocks, but only 2 of them are actually used for data transfer, allowing the system chipset to buffer the request and only hit RAM then deliver the result when it's truly needed. The actual memory bandwidth is the same in higher colour modes, but the balance shifts, so that the video system gets not just 4 out of every 8 memory accesses during the active drawing period, but 5, 6, or the full 8)
1 billion nanoseconds, divided by 140, gives you approximately 7.1MHz. The latency in this case is the time taken between the memory receiving the R/W access setup (with the address and type of request) on one clock tick, and being able to either deliver the Read data or accept the Write data on the next, and also the time between doing that and being ready to start again on the third tick. There's sufficient wiggle room with chips operating at 150ns, expecting a maybe less than perfect jitter from their host circuitry, that they can be safely run at 140 in most systems, or even 125 (=8MHz) if the voltage is strong enough and the signal swing fairly sharp.
(And in the PC, which operated at a touch less than 5MHz, 200ns would have been more than sufficient; 250ns is still within the realms of possibility, especially as it may well have inserted Wait States as a matter of routine anyway. If we go all the way to 400 or so, we're down into the realm of 2.5MHz operation; that's not even really enough to support a fast Z80, for which you might want 300 or even the full 250ns - memory that slow is limited more to older Z80/i8080 systems, or 6502/6800 based designs. Maybe you're confusing the operation of the shared-video-memory, higher-speed Amiga with the reference design for the 68000, which started off at just 5MHz and didn't expect anything but the CPU to access RAM directly, and therefore was entirely happy specifying much slower memory?)