• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

TechPowerUp RAM Latency Calculator Feedback

W1zzard

Administrator
Staff member
Joined
May 14, 2004
Messages
28,676 (3.74/day)
Processor Ryzen 7 5700X
Memory 48 GB
Video Card(s) RTX 4080
Storage 2x HDD RAID 1, 3x M.2 NVMe
Display(s) 30" 2560x1600 + 19" 1280x1024
Software Windows 10 64-bit
While working on the Arrow Lake DDR5 Memory Scaling review I got tired of doing the timing math manually, so I created a web app to make this more efficient


Feedback please. It is not designed to give specific recommendations for specific types of memory, just help with the math.
 
Could you make the field to be calculated disabled? :)
 
Mm, works well here, but the name/description might be a bit unclear to some - you describe it as calculating nanoseconds of latency and it’s called Latency Calculator, yet the field called “latency” is referring to timings (at least from my understanding). Just might be worth it to clean up the terminology overall.

Could you make the field to be calculated disabled? :)
Already is on my end, though I am on mobile currently.
 
Could you make the field to be calculated disabled? :)
Done

Mm, works well here, but the name/description might be a bit unclear to some - you describe it as calculating nanoseconds of latency and it’s called Latency Calculator, yet the field called “latency” is referring to timings (at least from my understanding). Just might be worth it to clean up the terminology overall.
Good question, I don't want to call it "Timing" calculator, because that software already exists and does something completely different

I had the "Latency" field as "tCL" before, which makes it more obvious to the uninformed, but it's technically not right, because the input can be used for all timings
 
@W1zzard
Hmmm, what if “Latency” is renamed to “Timings” to be more all encompassing and “Nanoseconds” to “Latency”? It’s still not ideal (not everyone understands what RAM timings even are), but will more directly connect the naming with the function. I am not sure how to make it even more clear to “the uninformed”, but the silver lining is that this is a somewhat specialist tool and random people aren’t likely to use it.
Might also want to note in the description that this still only calculates DRAM latency and expressly NOT end to end memory to CPU one for the system. Should be obvious, but there are all sorts out there.
 
Good idea for the calculator! How about adding a second set of boxes on the right so that differently specced modules can be compared?
 
If this is just a tool for convenience of info, perhaps a greyed-out info field with half the MT/s labelled MCLK or similar - It might also help clear up any confusion people have between MHz and MT/s?

I don't think anyone actually has difficulty dividing a number by two, but seeing behaviour confirmed by a tool is as educational as an explanation for some people.
 
It seems 6400 for am5 is the standard at the moment at 10ns.
 
12333 ns is displayed instead of 12.333 or 12,333 both in the input field and also in the table.

Is not one digit after decimal point/comma enough?
 
Last edited:
12333 ns is displayed instead of 12.333 or 12,333 both in the input field and also in the table.

Is not one digit after decimal point/comma enough?
Works for me. Which browser/OS + language setting?
 
Windows 10 Pro 22H2, both Firefox and Edge do not work, Czech language.
Same here. Firefox and Chrome in Win 7, and Firefox in Win 11, Slovenian language.

There are some issues with rounding too:
1730288648257.png

You enter 29, you get back 29.001 in the table. It seems that the latency in ns is calculated first, then rounded to 0.001, then calculated back to cycles.

As for the terminology, both numbers are "latency", one is in clock cycles, and the other in ns. You may want to include tooltips with brief explanations, for example, "Latencies in clock cycles are those that you see in manufacturers' specifications and on the memory modules" versus "Latencies in nanoseconds are REAL".
 
Last edited:
Windows 10 Pro 22H2, both Firefox and Edge do not work, Czech language.
Any better now?

You enter 29, you get back 29.001 in the table. It seems that the latency in ns is calculated first, then rounded to 0.001, then calculated back to cycles.
It should show cycles as full integers. This is probably fixed, now that I'm forcing en-US format on the numbers
 
"you should always use MT/s when talking about computer memory" - even if this calculator is of no use for LPDDR and GDDR, it would be better to say "computer memory on DIMMs" or something, because MT/s only really applies to those.
 
Here the behaviour is different than @BoggledBeagle 's.

Chrome (Win 7, Win 11) shows the comma in the input field. When entering ns, it takes both comma and point as decimal separators, which is probably fine, as we won't be dealing with thousand separators here.
1730290866579.png

Firefox (Win 7, Win 11) and Edge (Win 11) always display decimal point.

I enter 10.2 ns, I get back 10.323 in the table. Not sure what to suggest ... it's a bit confusing but at the same time it's correct because cycles are a whole number.

1730291476993.png


Suggestion for version 2.0: make it aware of different DDR generations (and maybe gear ratios too), so it can display a warning when an odd number is entered for DDR5, for example.
 
Last edited:
I enter 10.2 ns, I get back 10.323 in the table. Not sure what to suggest ... it's a bit confusing but at the same time it's correct because cycles are a whole number.
Nice find and good explanation. I looked into this, and I think the current behavior is better than fudging the nanoseconds to match the input

I can now see decimal points everywhere except in Edge and input field, where is a decimal comma.
The problem is the damn input type=number field, which apparently every browser treats slightly differently .. I'll work around this and make it a text field and add the + - buttons manually
 
Would be nice if the steps in MT/s are more accurate for DDR1/DDR2/DDR3/DDR4.

3733 to 3600 would be a more logical step

1730295280810.png
 
While working on the Arrow Lake DDR5 Memory Scaling review I got tired of doing the timing math manually, so I created a web app to make this more efficient


Feedback please. It is not designed to give specific recommendations for specific types of memory, just help with the math.
I find this a bit confusing.

If I choose data rate it looks locked into 6000 MT/s (when it should let me choose MT/s and clear other inputs) and I would expect to see iterations of latency and their respective timing in nanoseconds.

1730295739385.png


Back when I bothered to OC my DDR4 I had this little cheat sheet I made. It looks like you kind of making the same thing but for a single column at a time allowing the user to provide input.
1730296020988.png
 
If I choose data rate it looks locked into 6000 MT/s (when it should let me choose MT/s and clear other inputs) and I would expect to see iterations of latency and their respective timing in nanoseconds.
Isn't that what "Calculate" before the radio buttons would suggest? How to redesign?
 
Isn't that what "Calculate" before the radio buttons would suggest? How to redesign?
Just a few minutes... I will comment more and hopefully it will make sense.
  1. Option 1 choose MT/s
    1. allow input MT/s
    2. allow range input from Min Latency to Max Latency (set to some reasonable default for both based on market trends)
    3. allow range input from Min Nanoseconds to Max Nanoseconds (set to some reasonable default for both based on market trends)
    4. calculate table of MT/s by Latency resulting in Nanoseconds (allowing min/max values to limit result set)
  2. Option 2 choose Latency
    1. allow input Latency
    2. allow range input from Min MT/s to Max MT/s (set to some reasonable default for both based on market trends)
    3. allow range input from Min Nanoseconds to Max Nanoseconds (set to some reasonable default for both based on market trends)
    4. calculate table of MT/s by Latency resulting in Nanoseconds (allowing min/max values to limit result set)
  3. Option 3 choose Nanoseconds
    1. allow input Nanoseconds
    2. allow range input from Min MT/s to Max MT/s (set to some reasonable default for both based on market trends)
    3. allow range input from Min Latency to Max Latency (set to some reasonable default for both based on market trends)
    4. calculate table of MT/s by Nanoseconds resulting in Latency (allowing min/max values to limit result set)
For illustrative purposes if I take a single result set from my DD4 cheat sheet output for option 1 might look like below.

1730297073146.png
 
Last edited:
Calculate seems a bit disjointed from the three buttons, I would put it closer or even put a frame around the four items.
 
Perhaps putting the radio button next to the cell to be calculated, if that is feasible, would more accurately indicate their use.
 
@W1zzard Do you plan to make this more advanced with primary/sub-timings?
 
So I think my confusion with UI is this for example. If I choose to calculate nanoseconds I expected to see variations of nanoseconds at a constant Data Rate or constant Latency. Does this make sense or am I just using this wrong?

1730297603923.png
 
Back
Top