Ramulator-Gate Top Picks
The Mess paper took home a Best Paper Runner-Up. A few Ramulator-Gate statements deserve recognition too.
Memory bandwidth
A simulator result can look right for the wrong reason.
That is where the first chapter of Ramulator-gate begins.
At MICRO 2024, we published our paper on the Mess benchmark, showing how it can be used to evaluate the memory performance of real systems and simulators [1].
A year later, the Ramulator team published a preprint that characterized the Mess paper’s results and conclusions as incorrect due to “multiple trivial human errors” and “gross configuration errors” [2]. In 2026, this work was accepted to ISPASS [3]. The wording about “trivial” and “gross” errors was removed, but the main narrative remained.
We chose not to respond publicly to earlier preprints, despite what I consider serious misrepresentations of the Mess study. However, publication in an IEEE venue changes the situation.
In this series of posts, we will challenge several statements and results presented by the Ramulator team.
The first chapter of Ramulator-gate shows why better-looking results are not always the right results.
On one technical point, we agree with the Ramulator team: to resemble the bandwidth of the actual 8xDDR5-4800 Amazon Graviton3 and Intel Sapphire Rapids systems, Ramulator 2.0 requires a 16-channel DDR5-4800 configuration. With 8 channels, Ramulator 2.0 simulates roughly half of the expected bandwidth.
Where we disagree is whether the 16-channel Ramulator 2.0 configuration was obvious in this context.
This distinction matters.
The Ramulator team does not provide actual system measurements for the evaluated baseline and does not explicitly state that the baseline real systems are used to guide the simulator configuration. As a result, the 16-channel simulator configuration is presented in a way that appears more natural for an unspecified “ARM-based real system” than for Amazon Graviton3 with 8-channel DDR5-4800 main memory.
This is where narrative starts to diverge from the technical record.
And this is only the beginning.
In the next chapters, we will directly challenge the Ramulator team’s position that “channel” and “subchannel” are not distinct concepts in the DDR5 context.
Stay tuned!
-
Mess paper evaluation
- Real-system measurements
- Amazon Graviton 3: 8×DDR5-4800
Intel Sapphire Rapids: 8×DDR5-4800 - Ramulator 2.0 in the Mess paper
- 1×DDR5-4800 simulated in detail, bandwidth scaled ×8
System Max BW Amazon Graviton 3 · 8×DDR5-4800 292 GB/s Intel Sapphire Rapids · 8×DDR5-4800 264 GB/s Simulation: 1×DDR5-4800 scaled ×8: gem5 + Ramulator 2.0 141 GB/s Simulation: 1×DDR5-4800 scaled ×8: Trace-driven Ramulator 2.0 126 GB/s Conclusion
Max simulated BW ≈ ½ of the actual one.
-
Ramulator team re-evaluation
The Ramulator team does not provide actual system measurements for the evaluated baseline, and does not state that the baseline real systems guide the simulator configuration. As a result, the 16-channel configuration is presented as more natural for an unspecified “ARM-based real system” than for the 8×DDR5-4800 Amazon Graviton 3 it actually reproduces.
- Real system under study
- NOT SPECIFIED
- Real-system measurements
- NONE.
Reproducing “Mess results for an ARM-based real system” to Amazon Graviton 3: 8×DDR5-4800
System Max BW Reproduced from the Mess paper: Amazon Graviton 3 · 8×DDR5-4800 292 GB/s Simulation: 16×DDR5-4800 Trace-driven Ramulator 2.0 281 GB/s Conclusion
“By correctly configuring Ramulator 2.0, simulated memory performance resembles real system characteristics well.”
Correctly configuring here means using a 16×DDR5-4800 Ramulator 2.0 setup to simulate the 8×DDR5-4800 actual system.
From the Ramulator re-evaluation paper:
-
Discussion
On one technical point, we agree: to resemble the bandwidth of the actual 8×DDR5-4800 systems, Ramulator 2.0 needs a 16-channel DDR5-4800 configuration. Where we disagree is whether that 16-channel configuration was obvious in this context. This distinction matters.
- We agree
- To resemble the bandwidth of the actual Amazon Graviton 3 and Intel Sapphire Rapids systems, Ramulator 2.0 needs a 16-channel DDR5-4800 configuration.
- We disagree
- On whether the 16-channel Ramulator 2.0 configuration was obvious in this context.
- To date
- The Ramulator team has not acknowledged that Amazon Graviton 3 and Intel Sapphire Rapids have 8 memory channels, although Intel, Amazon and numerous independent resources state this. See the sources below.
Take out
To resemble the bandwidth of the actual 8×DDR5-4800 Amazon Graviton 3 and Intel Sapphire Rapids systems, Ramulator 2.0 needs a 16-channel DDR5-4800 configuration.
With 8 channels, Ramulator 2.0 simulates roughly half of the expected bandwidth.
References
- [1]Esmaili-Dokht et al. “A Mess of Memory System Benchmarking, Simulation and Application Profiling,” MICRO 2024. Best paper runner-up award.
- [2]Haocong Luo, Ataberk Olgun, Maria Makeenkova, F. Nisa Bostancı, Geraldo F. de Oliveira, A. Giray Yağlıkçı, Onur Mutlu, “Cleaning up the Mess,” arXiv Oct. 2025.
- [3]F. Nisa Bostancı, Haocong Luo, Ataberk Olgun, Maria Makeenkova, Geraldo F. de Oliveira, A. Giray Yağlıkçı, Onur Mutlu, “Cleaning up the Mess: Re-Evaluating the Real-System Modeling Accuracy of Ramulator 2.0”. ISPASS 2026.
DDR5 DIMMs: Channel vs. sub-channel
DDR5 channels and sub-channels: Terminology matters
In the previous post, we saw that some memory simulators require 16 DDR5 memory channels to simulate actual 8-channel systems, such as Intel Sapphire Rapids and Amazon Graviton 3.
In the next two posts, I will explain why this happens.
It took us 10 months of email exchange with the Ramulator team to understand the technical reasoning behind this setup: channel and sub-channel terminology in DDR5 DIMMs.
A common understanding today is that a DDR5 DIMM is connected to the CPU through a DDR5 channel, which is partitioned into two sub-channels. In the HPC domain, which is the focus of our studies, this terminology is broadly used.
At the same time, some sources use a different convention: 1 DIMM = 2 channels.
To make things even more interesting, these two conventions are sometimes mixed within the same document.
My objective here is not to criticize these inconsistencies.
The documents discussed in this post cover everything from DDR5 chips to HPC servers, so it is understandable that terminology may vary. Also, the sub-channel concept was introduced with DDR5 DIMMs, so the community may simply need more time to converge on a consistent convention.
My objective is to point to a practical problem:
To prevent confusion, especially when the intended meaning differs from the mainstream convention, the term “DDR5 channel” should be defined explicitly.
In the next post, I will explain why this discussion is directly relevant to the Ramulator-gate saga.
Stay tuned.
DDR5 DIMMs: Channel vs. sub-channel terminology map
Memory companies
Rambus and Micron use different terminology in different documents
Samsung, SK Hynix and Kingston consistently use one-DIMM/one-channel terminology
System view: CPU + DDR5 DIMMs
All CPU manufacturers consistently use one-DIMM/one-channel terminology
Hundreds of sources for:
Scientific studies
A vast majority of studies follows one-DIMM/one-channel terminology
Mess and Ramulator views
It is OK to disagree. The question is what you do when you disagree.
In the previous post, we discussed DDR5 DIMM channel and sub-channel terminology, and the inconsistencies that appear across different sources.
The Mess paper followed the commonly used terminology: a DDR5 DIMM is connected to the CPU through a single DDR5 channel, which is partitioned into two sub-channels. This is also how Intel and Amazon describe the memory organization of the servers that we benchmarked.
Ramulator 2.0, however, assumes two channels per DDR5 DIMM. Although this is not the mainstream use of the term “channel”, this convention does appear in some documents, as discussed in the previous post. The Ramulator authors also expressed their view that channel and sub-channel are not two distinct concepts in the DDR5 context. We still find this interpretation difficult to reconcile with the terminology used by the other sources we have found.
This difference between the mainstream understanding and the Ramulator 2.0 convention explains why “Number of channels: 16” is needed to simulate actual 8-channel DDR5 systems.
It took us 10 months of email exchange with the Ramulator team to detect this issue.
Some people argue that detecting it should have been obvious.
We would argue that it is obvious only in hindsight.
This issue could have been solved with a clarifying comment on “DDR5 channel” in the Ramulator 2.0 configuration or README files.
This was our proposal for an easy way forward.
The Ramulator team, however, took a different path.
Despite knowing that our DDR5-channel reasoning followed a mainstream view in academia and industry, the Ramulator team publicly presented our channel configuration as a “trivial human error” and a “gross configuration error”.
The most striking part is that the Ramulator team also states that “the misconfiguration of the number of channels in DDR5 could have been easily resolved by emails and collegial discussions.”
Indeed.
That is exactly what we tried to do.
For 10 months.
And this is precisely where the record matters more than the narrative.
Mess / BSC Memory Team
ONE DIMM: ONE CHANNEL,
TWO SUB-CHANNELS
Ramulator / ETH Zurich Ramulator Team
ONE DIMM: TWO CHANNELS
In addition: DDR5 channel and subchannel are not two distinct concepts
We started the email communication with the Ramulator team in October 2024, even before the Mess paper was published. After ten months of email exchange, we found the reason for the reported low memory bandwidth of Ramulator2.
1 27 Aug 2025 BSC Memory team → Ramulator team
We informed the Ramulator team that we found the reason for low Ramulator2 bandwidth reported in the Mess paper:
Ramulator2 does not differentiate between DDR5 channel and sub-channel. In the configuration file, setting the number of channels actually sets the number of sub-channels.
The Ramulator team's reply was unexpected.
2 12 Sep 2025 Ramulator team → BSC Memory team
The Ramulator team replied that, in their view, DDR5 channel and subchannel are not two distinct concepts.
BSC Memory team presented its position on DDR5 channel/sub-channel terminology and proposed a constructive way to resolve the issue.
3 16 Oct 2025 BSC Memory team → Ramulator team
Terminology position
We explained to the Ramulator team that in the context of the HPC servers with DDR5 DIMMs, which are the systems tested in the Mess paper, the community agrees that the memory channel is the interface between a DIMM and CPU memory controller, and that each DDR5 DIMM channel is divided into two independent sub-channels.
Constructive way forward
We also suggested that a straightforward way to ensure that all Ramulator2 users interpret the term “DDR5 channel” consistently with its intended meaning would be to include a clarifying comment in the simulator configuration or README files. We concluded that this would be a very nice outcome of this discussion that would improve the Ramulator2 setup.
These statements are limited to restoring a verifiable fact regarding the existence of this email discussion prior to the publication of the “Cleaning up the Mess” paper, with the aim of preserving a respectful, rigorous, and community-useful environment for scientific discussion.
Out of respect for the confidentiality of communications, we will not publish the full emails or their attachments, recipient lists, email addresses, literal excerpts, or screenshots of the thread that would allow the full content of the email exchanges between the two teams to be reconstructed. We have limited ourselves to minimal evidence consisting of communication dates, with the sender and recipient fields and the main messages exchanged redacted, while keeping the remaining information confidential.
In addition, we have also raised this matter through the internal channels made available by the organizations involved.
Ramulator-Gate paper · 17 Oct 2025
Their response
The question is what to do when you disagree …
View paper ↗Indeed.
That is exactly what we tried to do.
For 10 months.
Nope! Ramulator’s memory-channel configuration was not clear.
The Ramulator team argues that the intended Ramulator 2.0 configuration — using twice as many channels as the corresponding real systems — was clear.
And this is their strongest argument:
“the source code of Ramulator 2.0 clearly shows that a DDR5 channel is 32 bits wide in Ramulator 2.0”
Nope, not clear!
Ramulator 2.0 did contain a m_channel_width parameter with a default value of 32 bits.
src/ └─ dram/ └─ impl/ ├─ DDR5.cpp ├─ HBM2.cpp └─ LPDDR5.cpp
m_channel_width = param_group("org").param<int>("channel_width").default_val(32); At the time of the Mess paper:
- this parameter was not present or described in the configuration files
- it was not included in the user documentation or guides
- it was not documented or explained as a configurable parameter
This remained the case even in the artifact used by the Ramulator team in their response to the Mess paper.
Ramulator-gate response artifactconfigs/ddr5_4800an_16ch.yaml
View pinned source MemorySystem: DRAM: impl: DDR5 org: preset: DDR5_16Gb_x8 channel: 16 rank: 1 timing: preset: DDR5_4800ANm_channel_width parameter was not present or described in Ramulator 2.0 configuration filesHaving a 32-bit default value somewhere in the source code is plainly not the same as knowing how an actual system memory configuration should be mapped into the simulator.
The vendor documentation for the commercial systems we tested describes DDR5 using 64-bit (+ECC) channels — i.e., one-DIMM-per-channel, not half-DIMM-per-channel!
Ramulator 2.1 (March 2026) subsequently made channel_width part of the explicit DRAM organization.
"DDR5_16Gb_x8": {
"density": 16384,
"dq": 8,
"channel_width": 32,
"rank": 1,
"bankgroup": 8,
"bank": 4,
"row": 1<<16,
"column": 1<<10
},channel_width = dram["channel_width"].as<int>(); There is no fallback in this loader: Ramulator 2.1 presets explicitly define channel_width and subject it to consistency checks. This is clearly better than the Ramulator 2.0 configuration — at least the internal default channel width is now exposed much more explicitly.
During our 10-month email exchange, we suggested that the Ramulator team clarify this issue, but they rejected the very existence of 64-bit DDR5 channels.
If you have read this far, you definitely deserve something juicy. Here we go!
The Ramulator team provides some very convincing-looking numbers for DDR5 bandwidth and supports them with reference to the JEDEC DDR5 SDRAM standard.
Looks solid!
“The maximum bandwidth of an 8-channel DDR5-4800 [13] is 153.6 GB/s [13], not 307 GB/s.”
“Thus, a bandwidth of more than 153.6 GB/s should not be expected of an 8-channel DDR5-4800 configuration.”
But there are a few “Oops!” moments here.
Oops #1: Using references as decoration
The cited JEDEC standard:
- does not provide DDR5 per-channel bandwidth calculations;
- does not contain the values 19.2 GB/s or 153.6 GB/s — the bandwidth figures that the Ramulator team attributes to single-channel and eight-channel DDR5-4800 configurations.
The standard describes DRAM specifications, timing parameters, and electrical and architectural characteristics.
No relevant bandwidth numbers there!
But we have to admit: JESD79-5C is a great reference to attach to a questionable DDR5-related numerical claim. It is a long, highly technical document behind a $423 paywall, so the citation looks authoritative — and very few readers are likely to check whether the claimed numbers are actually there.
Academia at its finest!
Oops #2: The literature says 8-channel DDR5-4800 → 307 GB/s
Many studies support the BSC bandwidth calculation:
8-channel DDR5-4800 → 307.2 GB/s
They also report measurements on real systems that are consistent with this theoretical bandwidth.
And these studies are difficult to ignore — simply because there are so many of them.
Unless, of course, inconvenient evidence is simply left out of the discussion.
Today, we are playing a game!
I will show you three charts and you have to find the impostor, i.e. the Messed-up chart!
In this post, focus on memory-access latency (the y-axes). We’ve already discussed the bandwidth differences.
Let’s start with these charts.
It’s obvious! No need to think about it: the guy in Figure (a) is all squashed, while the other two look nice and tall.
And this is exactly what the Ramulator-gate paper (ISPASS 2026) concluded:
“To show that Ramulator 2.0, when configured properly and used correctly, yields reasonable and realistic bandwidth–latency curves, we evaluate a modern DDR5 memory system in Ramulator 2.0 using the same access patterns as described in the Mess benchmark”
“We conclude that Ramulator 2.0, when configured and used correctly, yields reasonable and realistic bandwidth–latency curves that resemble the ones obtained from real systems by [Mess paper] “
“The results we present in this section thus show that the Ramulator 2.0 results presented in [Mess paper] are incorrect and are not representative of Ramulator 2.0’s modeling accuracy and capability.”
Looks fair!
But that’s the problem: it only looks fair!
Let’s take a step back. Did you check the y-axes?
Oops… They are a bit different. Conveniently different…
Now, let’s replot the charts reproduced from the Ramulator-gate paper using the same y-axis scale. We’ve also marked the latency ranges in the unloaded and saturated regions of the curves.
(Mess paper)
Now we have only one tall guy — the actual system measurements in Figure (b) — while both Ramulator charts are squashed.
Based on these results, we can conclude that the real system must be wrong: its latencies don’t match those of the validated, cycle-accurate Ramulator 2.0, as shown by two independent studies [Mess@MICRO-2024, Ramulator-gate@ISPASS-2026] and the JESD-79 standard .
Or maybe, just maybe, as we concluded in the MICRO-2024 paper:
“The simulated memory latency is unrealistically low”
Academia at its funniest: Tips & Tricks
To evaluate a memory simulator’s latencies, just play with the y-axis until the results visually match your expectations!
Let’s start with some basics. The fun stuff will come later, I promise!
In integrated CPU–memory simulation platforms, memory-system performance can be evaluated at multiple points in the simulated execution pipeline. In this post, we focus on two of them: the memory-simulator and the application view.
The memory-simulator view uses statistics reported directly by the memory simulator. It captures how the simulator processes the memory requests it receives.
The application view measures the latency observed by the simulated CPU core, i.e., the application’s load-to-use latency for main-memory accesses.
Both views are useful, but they answer different questions. The memory-simulator view helps users track performance across the different stages of the integrated simulation infrastructure. The application view directly determines simulated application performance and is therefore the relevant measure of overall simulation accuracy.
Let’s apply this reasoning to ZSim connected to Ramulator through the DAMOV interface.
We start with the latest and most complete results, and then we contrast them with the reasoning of the previous studies. The BSC simulator configurations are compared with an Intel Skylake server with a 24-core CPU and 6xDDR4-2666 main memory. The Mess bandwidth-latency curves for this system are below.
Rd:Wr 50:50Rd:Wr 100:0
Result 1: Our ZSim-Ramulator configuration modeling the Intel Skylake system under study
Conclusions:
- Memory simulator view: Not perfect, not terrible.
- Application view: Oops! 25 ns latency across the entire realistic bandwidth range. The application is effectively decoupled from the detailed memory simulation.
Result 2: Since the Ramulator team keeps finding new ways to attribute our results to simulator misconfiguration, we repeated the experiment using the original DAMOV framework — a.k.a. Patient 0 .
It models 32 cores connected to 4× DDR4-2400 main memory (see Appendix A of our IISWC paper). The absolute bandwidth values therefore differ from those in other experiments, but that does not affect the qualitative behavior we are examining here.
Conclusions:
- Memory simulator view: Not bad at all! I actually like the shape of the curves in the saturated region.
- Application view: A constant 16 ns latency?! And I thought 25ns was bad...
The pattern so far:
Memory-simulator view: latency responds to increasing memory pressure.
Application view: latency remains almost constant at 16–25 ns.
Let’s take a step back and see how the Ramulator team evaluated the same integrated simulation platform.
Bostanci et al. @ ISPASS-2026. A.k.a. “The Ramulator-gate” paper.
They use a somewhat different memory configuration, 8×DDR4-2666. This changes the absolute bandwidth scale but does not affect the point we examine here.
Not reported
Oops … That is the view the simulated application actually sees
Application view
Conclusions:
- Memory simulator view:
“we observe that DAMOV’s memory access latency is not constant, in contrast to what is reported in the Mess paper. As system load increases, the memory access latency increases. We conclude that when correct DRAM statistics are used, DAMOV’s simulated memory access latency is not constant.”
“The DRAM performance metrics should come from Ramulator statistics output itself. The results in the Mess paper for DAMOV are reflecting incorrect statistics due to simulator usage error.”
- Application view: No results were reported.
This raises two obvious questions
- What is the purpose of this evaluation if the latency perceived by the simulated application is not reported?
- Was not reporting these results an honest oversight, or was it an intentional omission?
It was very difficult to argue about the intentions of other people. Still, we can safely say that the Ramulator team was well aware that of the core issue identified in the Mess paper: the memory-access latency calculated by Ramulator was not reflected in application execution. This is stated in the Mess paper, and reiterated several times in the email communication between the two teams.
On two occasions, we suggested to the Ramulator team a simple test that could expose this behavior: to run a pointer-chasing workload in ZSim+Ramulator and compare the latency perceived by the application (execution time / number of instructions) with the latency reported by Ramulator and the ZSim statistics.
So the Ramulator team reported the memory-simulator view while leaving the application view unreported, even though the main problem, ZSim–Ramulator interface, had already been explicitly identified and discussed between the two teams.
Funnily enough, Ramulator-gate provided a very detailed analysis on bandwidth implications of the all-bank periodic refresh operations. A good magician knows how to divert attention away from the part of the stage that matters!
And now, back to the controversial Mess paper: Esmaili et al. @ MICRO-2024.
“To exclude any simulation error caused by the CPU simulators or their memory interfaces, we perform a trace-driven Ramulator simulation.”
Conclusions:
- Application view: There it is again: approximately 25 ns of constant latency. Well, at least that is considerably better than the 16 ns produced by the original DAMOV framework!
- Memory simulator view: “trace-driven memory bandwidth–latency curves show better general trends than the corresponding Zsim-driven simulations. This indicates that a part of the ZSim+Ramulator simulation errors reported in [Application view] is caused by the simulators’ interfaces.”
Prior studies
Finally, the Mess paper’s findings are also consistent with the previous studies reporting integration problems between event-based CPU simulators and cycle-accurate memory models. Let’s check these studies!
Both studies, from established simulation research groups, identify fundamental integration problems between loosely synchronized parallel CPU simulators, such as ZSim, and delayed-response cycle-accurate memory models, such as Ramulator.
This integration issue explains the unrealistically low and nearly constant memory-access latencies observed in the application view. For a detailed explanation of how and why the application’s perception of memory performance becomes effectively decoupled from the detailed memory simulation, see our IISWC-2026 paper.
Mess reproducibility has a date. So do the Ramulator team’s false claims.
The Ramulator team raised serious concerns about the reproducibility of the results presented in the Mess paper — the paper that received the Best Paper Runner-Up Award at MICRO 2024, together with all three artifact badges: Available, Reviewed and Reproducible.
The reproducibility of the Mess results is supported by publicly available artifact repositories:
The Ramulator-gate paper contains so many reproducibility-related claims that going through every one of them would make for a very long post. We therefore focus on one concrete example: the reproducibility of the ZSim+Ramulator results. The other claims follow a similar pattern.
“We carefully checked the artifact repositories of the Mess paper based on the description of the artifact in Appendix C of [the Mess paper]. Unfortunately, we could not find the following three items used by the Mess paper to produce the results in Fig. 5 (f) in the Mess paper:1) the source code of the ZSim simulator,2) the source code of Ramulator, and3) the configuration of Ramulator used.”
And here is what the documented record actually shows:
(1) The source code of the ZSim simulator
The ZSim source code has been publicly available in the Mess simulator repository since 14 August 2024.
Repository location: https://github.com/bsc-mem/Mess-simulator/tree/main/Integrated/ZSim/ZSim
This repository location was discussed in documented email communication initiated on 17 October 2024 and was explicitly shared with the Ramulator team on 6 November 2024.
6 November 2024BSC Memory team → ETH Zurich Ramulator team
In this email exchange, the BSC Memory team provided links to the public Mess artifact repository, together with the files and instructions needed to reproduce the ZSim+Ramulator and trace-driven Ramulator experiments.
ZSim+Ramulator:
- ZSim source code
- Detailed simulation outputs for every point on the bandwidth–latency curves, together with instructions on how to interpret them
- All relevant configuration files
Trace-driven Ramulator experiments:
- All traces used in the trace-driven Ramulator experiments
- All relevant configuration files
Reconfirmed on 14 October 2025
14 October 2025BSC Memory team → ETH Zurich Ramulator team
In this email exchange, the BSC Memory team again provided the link to the public Mess artifact repository containing the ZSim source code used in the paper.
The BSC team also explained — once again — that the core issue is that the memory-access latency calculated by Ramulator is not reflected in application execution.
We reiterated that this issue is explicitly discussed in the Mess paper as an interface problem, together with references to previous studies that examine it in greater detail.
We also provided a screenshot of Fig. 3 from Shang Li et al., Rethinking Cycle Accurate DRAM Simulation (MEMSYS 2019), which illustrates the issue.
The BSC Memory team concluded the discussion with two simple points:
1. A simple test can expose the ZSim–Ramulator interface problem
We suggested that the Ramulator team run a simple test that can directly reveal the ZSim–Ramulator interface issue identified and described in the Mess paper:
Run a pointer-chase benchmark in ZSim+Ramulator and compare the latency perceived by the application (execution time / number of instructions) with the latency reported by Ramulator.
It really cannot get simpler than that.
But evidence is easy to overlook when it points in an inconvenient direction.
2. The application must see the memory latency produced by the DRAM model
The purpose of integrating ZSim with a cycle-level DRAM model is for applications running on ZSim to experience the memory-access latency produced by that model. Yet this was still not happening in the ZSim+Ramulator integration — even one year after we first reported the problem.
If you would like to understand why the application’s perception of memory performance becomes effectively decoupled from the detailed memory simulation in the ZSim+Ramulator infrastructure (DAMOV interface), see our IISWC-2026 paper, Integration, Enhancements and Evaluation of Memory Simulators.
We also present a high-level analysis in our previous post.
(2) The Ramulator source code
The Mess paper explicitly states (Section IV.B):
“ we use … ZSim+Ramulator from the SAFARI Research Group
at the ETH University (Ramulator developers) [73]”
The implementation used corresponds to the DAMOV platform, developed by the Ramulator team itself.
This information was reiterated in the documented communication dated 6 November 2024:
6 November 2024BSC Memory team → ETH Zurich Ramulator team
In this email exchange, the BSC Memory team explained that the ZSim+Ramulator results were obtained using the ZSim interface and the Ramulator version from the DAMOV repository, maintained by the Ramulator team. The BSC Memory team also explicitly shared the link to that repository.
(3) The Ramulator configuration used
The Ramulator configuration file was shared in the email dated 6 November 2024:
6 November 2024BSC Memory team → ETH Zurich Ramulator team
In this email exchange, the BSC Memory team provided the Ramulator configuration file used for the ZSim+Ramulator experiments.
Attachment: DDR4-config.cfg
Overall communication
Formal communication between the BSC Memory team and the ETH Zurich Ramulator team regarding the Mess study was initiated by the BSC team on 17 October 2024, before the Mess paper was published and presented at the conference.
Over the following ten months, the BSC Memory team provided detailed technical support and responded to the technical questions raised by the ETH Zurich Ramulator team. The materials required to reproduce the relevant Ramulator and Ramulator 2.0 results had been made available well before the publication of Cleaning up the Mess: Re-Evaluating the Real-System Modeling Accuracy of Ramulator 2.0 (a.k.a. the Ramulator-gate paper).
However, the published paper still contains multiple statements regarding the reproducibility of the Mess results that are contradicted by the documented record presented above.
Taken together, these statements may affect readers’ perception of the Mess paper’s transparency and reproducibility in a way that unfairly compromises the research work presented in the paper.
These statements also raise concerns in light of the Ordinance of ETH Zurich governing the procedure to address allegations of scientific misconduct, in particular:
- False statements made in a scientifically relevant context (Art. 4)
- Unfairly compromising the research work of others (Art. 4)
The Mess paper measures two real systems and simulates Ramulator 2.0 against them. The detailed single-channel run is scaled ×8, and the simulated peak lands at roughly half of the measured bandwidth.