{"id":"632f7502-87a5-4cec-af7a-e9a4a6fc9af9","arxiv_id":"2506.10931","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"MARS places raw-signal nanopore read mapping inside the SSD using near-DRAM and in-DRAM compute units, and is simulated to be 28x to 93x faster than current pipelines.","lead":"This paper proposes MARS, a design that performs raw-signal genome analysis inside a solid-state drive, using the SSD's own DRAM and controller to compute on genomic signals without moving them to the host. Simulations suggest MARS can be 28x to 93x faster and hundreds of times more energy-efficient than existing software and hardware pipelines, pointing toward real-time analysis on storage devices.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The evaluation assumes raw signal data is already placed sequentially and evenly across SSD channels (Sec. 7); since MARS's human-genome throughput is only 1.2x the MinION rate (Table 4), unmodeled ingestion or reorganization cost could erase the real-time claim.","rationale":"The reader identified the data-placement assumption as the weakest point; I agree and sharpen it with a quantitative observation: for the human genome dataset D5, MARS's reported throughput (286,728 bp/s) is only 1.24x the MinION sequencing rate (230,400 bp/s), so the unmodeled cost of ingesting and placing streaming raw data is not a second-order effect but a direct threat to the paper's real-time claim. The correctness of the central performance comparison (93x/40x/28x speedups) depends on MARS being able to process data as it is generated, and the evaluation explicitly assumes away the mechanism by which that data would be placed in the required layout. This is more load-bearing than the accuracy issue (the intro claims accuracy 'on par' with basecalling while Table 3 shows F1=0.7612 for D5 vs the 1.0 ground truth), because even if accuracy were perfectly acceptable, the performance claim would still rest on the ideal placement assumption. The concern is an evaluation limitation rather than an internal contradiction, and it can be addressed by modeling the ingestion phase; hence the reader's CONDITIONAL verdict remains appropriate and I recommend no change to the verdict.","tokens_in":35337,"tokens_out":11433,"duration_ms":128596,"concrete_test":"Extend the MQSim-based evaluation for D5 to include an ingestion phase: simulate raw fast5 chunks arriving from the sequencer at 230,400 bp/s, being written through the MARS FTL into the striped physical layout, while MARS concurrently processes previously ingested data. Measure the steady-state end-to-end throughput; if it falls below 230,400 bp/s, the human-genome real-time claim (Table 4) is invalidated. If such a full simulation is too heavy, analytically compute the controller and flash write overhead of ingesting 39 GB of raw data during the sequencing window and add it to MARS's D5 latency; any increase above roughly 18% breaks real-time.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 7 states: \"we assume that the data is already correctly placed, i.e. sequentially and evenly distributed across all SSD channels, for all evaluated systems.\" This placement is load-bearing: MARS's custom L2P mapping (Sec. 6.5) stores only a starting LPA, database size, and a sequence of PBAs, which works only if the genome index and raw signals are contiguous and striped across flash channels. In a real deployment, raw signals stream from a nanopore sequencer over time. The cost of writing those signals into the SSD in this striped log-structured layout, or of reorganizing them after arrival, is not modeled. This matters concretely: Table 4 gives MARS a throughput of 286,728 bp/s for D5 (human), while the full MinION sequencer produces 230,400 bp/s (ref. [150]), a margin of only 1.24x. Any additional data movement, FTL write overhead, or resource contention during ingestion would drop MARS below the sequencer rate, breaking the real-time claim that motivates the entire work. For smaller genomes the margin is larger, but the largest dataset is precisely the one where the paper claims a real-time capability. The baselines also assume pre-placement, but MARS's reliance on a minimal L2P mapping makes it uniquely sensitive to this assumption.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper identifies I/O data movement as the dominant bottleneck for raw-signal genome analysis (RSGA) once seeding and chaining are computationally accelerated, and proposes MARS, an in-storage processing system that places the RSGA read-mapping pipeline inside an SSD. MARS combines processing-using-DRAM (pLUTo-style hash-table query units inside the SSD-internal DRAM), processing-near-DRAM (arithmetic units near DRAM subarrays), and processing-near-DRAM logic in the SSD controller (sorter/merger units), together with software modifications: frequency filtering, seed-and-vote filtering, early quantization, and fixed-point arithmetic. The evaluation uses MQSim, CACTI7, Verilog synthesis, and data-movement latency calculations on five real datasets, and the paper claims 93x/40x speedups over a GPU-based basecalling pipeline (BC) and GenPIP, 28x over RawHash2, with energy reductions of 427x/72x/180x on average. Accuracy is reported as on par with or better than RawHash2 and close to a basecalling ground truth.","tokens_in":35582,"tokens_out":6515,"duration_ms":72984,"significance":"If the claimed results are reliable, MARS is a significant contribution: it is the first ISP system for RSGA, it is the first architecture to combine processing-using-DRAM and processing-near-DRAM inside a storage device, and its motivational analysis of the I/O bottleneck for accelerated RSGA is timely and well framed. The software modifications (early quantization and the combination of two filtering techniques) also appear to improve accuracy over RawHash2 in the reported settings. However, the evaluation is entirely simulation-based with no released code or data, and several load-bearing assumptions and an internal inconsistency in the accuracy reporting need to be resolved before the headline speedup and energy claims can be taken at face value.","major_comments":[{"comment":"The evaluation assumes that input data is 'already correctly placed, i.e. sequentially and evenly distributed across all SSD channels, for all evaluated systems' (Section 7). This assumption is load-bearing because MARS's custom L2P mapping in Section 6.5 stores only a starting LPA, the database size, and a sequence of PBAs, which works only if the reference index and raw signals are contiguous and striped across flash channels. In a real deployment, raw signals arrive as a stream from the sequencer and must be ingested or reorganized into this layout, and that cost is not modeled. Table 4 shows that the human-genome throughput of 286,728 bp/s is only 1.24x the full MinION rate of 230,400 bp/s, so even a modest ingestion or FTL-write overhead would erase the real-time margin for the largest dataset. Please add a quantitative ingestion/reorganization model, or explicitly scope the real-time claim to pre-placed data.","section":"Section 7 (Datasets) and Section 6.5"},{"comment":"Section 8.1 states that 'All hardware systems implement MS-CPUFloat workflow and thus achieve the same accuracy,' yet Section 7 lists MARS as the in-storage design using fixed-point arithmetic, with MS-CPUFixed as the CPU fixed-point variant. Because the hardware MARS uses fixed-point arithmetic, its accuracy should follow the MS-CPUFixed row of Table 3, not the MS-CPUFloat row. This discrepancy matters for the accuracy-parity claim: the D5 F1 values are 0.7612 for MS-CPUFloat versus 0.7300 for MS-CPUFixed. Please clarify which arithmetic MARS actually implements and report the corresponding accuracy consistently.","section":"Section 8.1 vs. Section 7"},{"comment":"End-to-end performance is assembled by simulating each component individually and adding data-movement latencies, but the architecture description relies on overlap: Section 6.3 says that for partitioned indexes 'MARS overlaps computation with data loading, effectively hiding the data movement latency,' and Section 6.1.3 says compute units are activated whenever their inputs are available. The paper does not explain how the component-wise simulations account for this overlap or for contention among Arithmetic, Querying, Sorter, and Merger Units. In addition, the Querying Unit's sequential row-sweep cost in Section 6.3 is central to the reported seeding speedups, yet the simulation configuration in Table 1 provides no description of how row activations, matchline delays, or repeated sweeps over partitioned hash-table chunks are modeled. Please provide an end-to-end timing model that includes these effects or quantifies why they are negligible.","section":"Section 7 (Evaluation Methodology) and Section 6.3"},{"comment":"The filtering thresholds (thresh_freq, thresh_voting, voting_window) are tuned on a 0.5%-2% subset of each dataset, and Table 3 reports accuracy on the full versions of those same datasets. Because the thresholds directly determine how many seeds and anchors survive to chaining, they affect both the F1 scores in Table 3 and the speedups in Fig. 11; reporting in-sample results may therefore overstate accuracy and performance. Please add held-out evaluation or a sensitivity analysis showing that the reported conclusions are stable across reasonable threshold choices.","section":"Section 5.1 and Table 3"}],"minor_comments":[{"comment":"The figure artwork contains explicit editing instructions that must be removed before publication: 'Improve text that fits to the figure', 'Show it is a sequence', 'Dotted lines call it step 1/2/3 etc', and 'Include that the current key is O'.","section":"Figure 9"},{"comment":"The text says 'all seven systems' but Section 7 lists nine evaluated systems: BC, RH2, MS-CPUFloat, MS-CPUFixed, MARS, MS-EXT, MS-SIMDRAM, GenPIP, and MS-SmartSSD.","section":"Section 8.2"},{"comment":"The label 'Contol Unit' should be corrected to 'Control Unit'.","section":"Figure 10"},{"comment":"The paper states that multiple copies of the hash table can be stored in DRAM, but it does not quantify how many copies fit in the 4 GB internal DRAM alongside raw signals, intermediate results, and FTL metadata; please provide this analysis.","section":"Section 6.3"},{"comment":"The manuscript does not state whether code or data will be released, which limits reproducibility of a fully simulated design; please add an availability statement.","section":"General"}],"recommendation":"major_revision","confidential_remarks":"The paper is within scope and the core idea is promising, but the verification of the headline claims depends on modeling assumptions that are either untested (data placement, query-unit sweep costs, overlap) or internally inconsistent (fixed-point vs float accuracy). I would not consider acceptance until these are resolved with a clear end-to-end timing model and consistent accuracy reporting."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Here's my read on MARS. It is a genuine systems contribution: the first in-storage processing design for raw-signal genome analysis, and the first to combine Processing-Using-DRAM and Processing-Near-DRAM inside an SSD. The motivational study (Section 3) makes the I/O bottleneck point concretely by showing that as seeding and chaining are accelerated, storage I/O dominates. That is a real observation, and it is the right justification for moving compute into the SSD. The architecture is carefully partitioned across the SSD controller, internal DRAM subarrays, and DRAM periphery, and the paper is unusually thorough in describing the querying, sorting, and arithmetic units. The area and energy numbers are plausible given the component-level synthesis and CACTI/MQSim simulations.\n\nThe soft spots are mostly about evidence, not about the idea. All results come from simulation: MQSim, CACTI7, and Verilog synthesis, combined with hand-computed data movement. There is no end-to-end validation against real hardware, no released artifact. That is typical for a complex architecture paper, but it means the 93x/40x/28x speedups should be read as modeled, not measured. The more specific concern is the data placement assumption in Section 7: data is assumed to be already sequentially and evenly striped across channels. MARS's custom L2P mapping depends on that layout. In a real deployment, raw signals arrive over time from the sequencer, and the cost of ingesting them into that layout is not modeled. The stress-test note gets this right: for the human genome (D5), MARS's throughput is 286,728 bp/s versus the MinION's 230,400 bp/s, a 1.24x margin. Any non-trivial ingestion or reorganization overhead could erase the real-time claim. For smaller genomes the margin is large, so the architecture still looks sound for viral and bacterial workloads.\n\nThe threshold tuning on 0.5-2% subsets of each dataset is a mild overfitting risk, since the same subsets are inside the evaluated data. It does not invalidate the accuracy comparison, but it should be disclosed more carefully. The leftover editing notes in Figures 1 and 9 (\"Replace in Overleaf\", \"Improve text that fits to the figure\") are sloppy and should be fixed before publication. I don't see a mismatch between the abstract's 28x and the Figure 11 geomean; the numbers line up.\n\nBottom line: this is a strong architecture paper with a novel integration and an honest, mostly transparent evaluation. The data-placement assumption is the one load-bearing assumption that needs a sensitivity analysis or an argument for why streaming writes naturally produce that layout. It deserves serious peer review, not a desk reject, with requests for artifact release and a sensitivity study on ingestion. I would bring it to the reading group; it will generate a good discussion about what it takes to make real-time genomics work inside storage.","headline":"A serious systems paper that makes a genuine case for in-storage RSGA; the speedups are simulated, and the human-genome real-time margin is thin enough that the data-placement assumption needs scrutiny.","tokens_in":36191,"tokens_out":4389,"would_cite":true,"duration_ms":47989,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"MARS claims 93x faster nanopore read mapping by moving analysis into the SSD.","keywords":["in-storage processing","raw signal genome analysis","nanopore sequencing","processing-in-memory","read mapping","SSD","DRAM acceleration","basecalling"],"falsifier":"Run MARS on a live stream of raw nanopore signals as the sequencer produces them, including the time to flush FTL metadata and arrange the data across channels, and compare end-to-end latency to RawHash2 reading from preloaded host DRAM; if the ingestion pass erases the 28x gap, the I/O-elimination claim is conditional on pre-arranged data placement.","tokens_in":35120,"feed_emoji":"🧬","tokens_out":5650,"duration_ms":59489,"temperature":0.7,"pith_summary":"This paper tries to establish that the dominant bottleneck in real-time nanopore genome analysis is no longer computation but the movement of raw signal data out of storage, and that the remedy is to execute the raw-signal read-mapping pipeline inside the SSD itself. To that end it proposes MARS, which it claims is the first in-storage processing system for raw-signal genome analysis, combining Processing-Using-DRAM (hash lookup inside the SSD's internal DRAM) with Processing-Near-DRAM (arithmetic units near DRAM subarrays and sorter/merger units in the SSD controller). A sympathetic reader would care because, if the claims hold, real-time mapping of large genomes would require neither basecalling nor shipping gigabytes of signals to host memory, with large energy savings. The paper reports 93x speedup over a GPU-based basecalling pipeline, 40x over a PIM-based basecalling pipeline, and 28x over RawHash2, with energy reductions of 427x, 72x, and 180x respectively, while keeping mapping accuracy on par with basecalling-based pipelines.","feed_headline":"MARS runs genome mapping inside the SSD, claiming 93x speedup","feed_subtitle":"Raw nanopore signals are analyzed without basecalling or host I/O, cutting energy by up to 427x.","key_machinery":"The load-bearing mechanism is the in-SSD pipeline itself, organized around four compute elements: an Arithmetic Unit per pair of DRAM subarrays that performs add/compare/multiply operations for event detection and hash-value generation (Processing-Near-DRAM), a Querying Unit per subarray that uses DRAM row activation, custom match logic, and gated sense amplifiers to look up hash values in parallel (Processing-Using-DRAM), and a Sorter/Merger pair per flash controller that implements bitonic sorting and one-pass merging inside the SSD controller. These are tied together by a MARS Control Unit, a finite-state machine that sequences the steps, and a custom log-structured logical-to-physical mapping that lets data be read sequentially across flash channels, so the raw signals and reference index are processed as a streaming flow that never leaves the device.","core_discovery":"On the paper's own terms, the discovery is that hardware acceleration of raw-signal genome analysis only exposes a second bottleneck: once seeding and chaining are made fast, storage I/O accounts for up to 78% of end-to-end time, so any scalable RSGA system must be storage-centric. MARS is the proposed proof of concept: it runs the whole RSGA workflow inside a modern SSD, with event detection and quantization on near-DRAM arithmetic units, hash-table seeding by processing-using-DRAM row activation with gated sense amplifiers, and chaining via bitonic sorter/merger units in the SSD controller, all orchestrated by a finite-state-machine control unit with a log-structured address mapping that turns the genome index and raw signals into a sequential in-device stream. To fit the pipeline into the device, MARS adds two filters (frequency filtering and seed-and-vote, the latter applied to raw signals for the first time) and early quantization with 16-bit fixed-point arithmetic, which the paper shows costs little accuracy. The paper claims MARS matches or exceeds the accuracy of the RawHash2 software baseline while delivering the speedups and energy reductions stated in the abstract.","pith_inferences":["The paper does not model the cost of ingesting and reorganizing raw signals as they stream from the sequencer; if a data-placement pass is required before MARS can start, its end-to-end advantage over in-memory baselines could shrink.","The same event-detection/quantization/hash-query/sort structure appears in other nanopore signal analyses such as methylation or RNA-modification detection, so the storage-centric recipe may transfer to those tasks if their accuracy tolerates the same filtering.","A fair test of the central claim would compare MARS against RawHash2 with the raw signals already resident in host DRAM, isolating the I/O-elimination benefit from the filtering and fixed-point algorithmic gains.","The speedup numbers assume a performance-optimized SSD with 4 GB internal DRAM; the paper's own sensitivity analysis shows MARS scales with DRAM size, which suggests the design's benefits depend on continued growth of SSD-internal DRAM capacity."],"forward_implications":["MARS reports throughput above the full MinION sequencer rate for all five datasets, so real-time nanopore read mapping becomes plausible without a server-grade host.","The basecalling step can be bypassed for read-mapping workloads, since filtering and quantization of raw signals alone give mapping accuracy comparable to basecalling-based pipelines.","The combination of Processing-Using-DRAM and Processing-Near-DRAM inside one SSD broadens the design space for in-storage acceleration of other data-intensive applications.","If the I/O-dominance analysis is right, future RSGA accelerators that ignore storage placement will deliver shrinking end-to-end returns as sequencing throughput grows.","The paper's comparison against an external-PIM variant (MS-EXT) implies that keeping computation in the device, not just accelerating it, is what yields the largest gains."],"supporting_citations":[{"why":"RawHash2 is the state-of-the-art RSGA read mapping baseline whose runtime breakdown motivates the I/O bottleneck and against which MARS reports the 28x speedup.","marker":"[39]"},{"why":"minimap2 is the read mapper in the GPU-basecalling baseline BC and is used to generate ground-truth mappings for accuracy evaluation.","marker":"[15]"},{"why":"Dorado is the GPU basecaller used in the BC pipeline, which MARS claims to outperform by 93x.","marker":"[63]"},{"why":"GenPIP is the state-of-the-art PIM-based basecalling read mapping pipeline that serves as the 40x hardware comparison point.","marker":"[37]"},{"why":"pLUTo supplies the Processing-Using-DRAM lookup-table mechanism that the Querying Unit is based on.","marker":"[118]"},{"why":"FULCRUM supplies the near-DRAM arithmetic unit design that MARS's Arithmetic Unit is inspired by.","marker":"[119]"},{"why":"MQSim is the SSD simulator used to evaluate the in-storage components and their data movement.","marker":"[90]"},{"why":"UNCALLED provides the real-time raw-signal mapping context and the pafstats tool used to compute mapping accuracy metrics.","marker":"[12]"},{"why":"The seed-and-vote filtering technique is adopted and, for the first time, applied to raw signals in this paper.","marker":"[61]"}],"fun_headline_variants":["MARS performs genome mapping inside the SSD, reports 93x speedup","Storage-centric MARS: 93x faster genome analysis, 427x less energy","MARS pushes raw signal analysis into storage, 93x speedup","Genome mapping moves into the SSD: MARS says 93x faster","MARS: in-storage genome analysis, 93x speedup over basecalling"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The evaluation assumes input data is already placed sequentially and evenly across the SSD's flash channels, so the cost of ingesting and reorganizing raw signals as they stream from a real sequencer is not included.","fun_headline_variants_meta":{"raw":{"variants":["MARS performs genome mapping inside the SSD, reports 93x speedup","Storage-centric MARS: 93x faster genome analysis, 427x less energy","MARS pushes raw signal analysis into storage, 93x speedup","Genome mapping moves into the SSD: MARS says 93x faster","MARS: in-storage genome analysis, 93x speedup over basecalling"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000322,"raw_usage":{"total_tokens":1892,"prompt_tokens":1110,"completion_tokens":782,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":726,"completion_tokens_details":{"reasoning_tokens":677}},"tokens_in":726,"tokens_out":782,"duration_ms":7801,"temperature":1.0,"reasoning_tokens":677,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T04:13:24.229738+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run MARS on a live stream of raw nanopore signals as the sequencer produces them, including the time to flush FTL metadata and arrange the data across channels, and compare end-to-end latency to RawHash2 reading from preloaded host DRAM; if the ingestion pass erases the 28x gap, the I/O-elimination claim is conditional on pre-arranged data placement.","supporting_citations":[],"review_version":1}