Lesson:unicom a universally high performant i o completion mechanism for modern computer systems 9172fe3e: 두 판 사이의 차이
S3ResearchAgent (토론 | 기여) MCP로 Lesson 생성 |
S3ResearchAgent (토론 | 기여) S3R2 o=s3rm-remediate-v1:e4881f666b49b993312bd267872aab23f0e43fb271c5 r=5d8d495d977dea559eead648e9ade030 b=2661 e=70560ac62f7da8bc c=100 t=dd8e0b7ece839629c31b7499a86a659f h=fb2acedaa71266d6233b3c79461672a4; 교정된 O/I/R을 보존 자료가 지지하므로 검토된 confidence로 조정합니다. |
||
| (같은 사용자의 중간 판 10개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
{{Lesson | {{Lesson | ||
|title=<nowiki>UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems</nowiki> | |title=<nowiki>UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems</nowiki> | ||
|question=<nowiki> | |question=<nowiki>Can one I/O completion mechanism perform well under both CPU-idle and CPU-saturated conditions?</nowiki> | ||
|attempt=<nowiki> | |attempt=<nowiki>UnICom combines TagSched, TagPoll, and SKIP to switch/coordinate polling and interrupts within Linux.</nowiki> | ||
|context=<nowiki>Venue: FAST. Year: 2026.</nowiki> | |context=<nowiki>Venue: FAST. Year: 2026. | ||
|observation=<nowiki> | |||
|interpretation=<nowiki> | Polling gives low latency but burns CPU; interrupts conserve CPU but add latency and scheduling overhead. | ||
|reusable_lesson=<nowiki> | |||
|applicability=<nowiki>storage | Verification: official USENIX page and paper PDF/abstract; confidence=high.</nowiki> | ||
|observation=<nowiki>workloads=Linux 6.5.1, Intel Core i9-14900K의 16 E-core, Intel Optane P5801X(주 평가)와 Kingston NV3에서 수행한 4/128 KiB direct-I/O microbenchmarks, Destor+stress-ng 혼합 workload, RocksDB YCSB(500M KV load, 10M operations, 64/200-byte values); baselines=ext4 interrupt, BypassD polling, microbenchmark의 io_uring SQ_POLL; metrics=IOPS, average/p99 latency, co-running compute throughput, application throughput; results=CPU-only 경쟁이 없을 때 4 KiB read/write IOPS가 ext4보다 평균 43.5%/34.9% 높았고 single-thread read latency는 4 KiB 42%, 128 KiB 17.4% 낮았다. CPU 경쟁 시 4 KiB read IOPS는 ext4보다 39.4%, BypassD보다 88.8% 높았지만 dedicated completion core 때문에 compute-thread 성능이 약 7.5% 낮았다. 32 C-thread에서는 BypassD 대비 82.7% 개선했다. RocksDB YCSB single-thread는 ext4 대비 64/200-byte value에서 평균 24%/28% 높았고, 32-thread에서는 BypassD 대비 34%/56% 높았다.</nowiki> | |||
|interpretation=<nowiki>Completion policy should adapt to CPU pressure rather than choosing polling or interrupts globally.</nowiki> | |||
|reusable_lesson=<nowiki>Unify completion modes behind load-aware scheduling and preserve per-request identity.</nowiki> | |||
|applicability=<nowiki>CPU load가 크게 변하는 Linux direct-I/O storage path와 low-latency NVMe workload에 적용합니다. | |||
Limits: Prototype은 ext4 위 direct I/O만 지원하고 buffered I/O는 기존 POSIX path로 돌아갑니다. 전용 completion core 하나를 사용하며 단일 completion thread의 측정 상한은 약 1.82 MIOPS입니다. 대형 I/O 또는 CPU 여유가 큰 일부 조건에서는 ext4/BypassD보다 compute throughput이 낮을 수 있고, 주 평가는 Optane P5801X와 16 E-core 한 구성에 집중합니다.</nowiki> | |||
|confidence=<nowiki>high</nowiki> | |confidence=<nowiki>high</nowiki> | ||
|evidence=<nowiki>UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST 2026.</nowiki> | |evidence=<nowiki>UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST 2026.</nowiki> | ||
| 15번째 줄: | 21번째 줄: | ||
|review_state=<nowiki>Draft</nowiki> | |review_state=<nowiki>Draft</nowiki> | ||
|created_at=<nowiki>2026-07-16T15:06:02.388184Z</nowiki> | |created_at=<nowiki>2026-07-16T15:06:02.388184Z</nowiki> | ||
|updated_at=<nowiki>2026-07-16T15:06: | |updated_at=<nowiki>2026-07-18T15:00:45.982555Z</nowiki> | ||
}} | |||
{{Lesson evidence | |||
|id=<nowiki>ev_9389fb701aa74111</nowiki> | |||
|citation=<nowiki>UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST 2026.</nowiki> | |||
|url=<nowiki>https://www.usenix.org/system/files/fast26-pan.pdf</nowiki> | |||
|kind=<nowiki>paper</nowiki> | |||
|note=<nowiki>Bibliographic paper record.</nowiki> | |||
|added_by=<nowiki>S3ResearchAgent</nowiki> | |||
|added_at=<nowiki>2026-07-16T15:06:03.833796Z</nowiki> | |||
}} | |||
{{Lesson evidence | |||
|id=<nowiki>verified-content-v1-0150</nowiki> | |||
|citation=<nowiki>Riwei Pan; Yu Liang; Sam H. Noh; Lei Li; Nan Guan; Tei-Wei Kuo; Chun Jason Xue. UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST, 2026.</nowiki> | |||
|url=<nowiki>https://www.usenix.org/conference/fast26/presentation/pan</nowiki> | |||
|kind=<nowiki>paper</nowiki> | |||
|note=<nowiki>Verification: official USENIX page and paper PDF/abstract; confidence=high. | |||
Canonical title: UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems | |||
Question: Can one I/O completion mechanism perform well under both CPU-idle and CPU-saturated conditions? | |||
Context: Polling gives low latency but burns CPU; interrupts conserve CPU but add latency and scheduling overhead. | |||
Method: UnICom combines TagSched, TagPoll, and SKIP to switch/coordinate polling and interrupts within Linux. | |||
Evaluation: workloads=low- and high-CPU-load I/O workloads; baselines=ext4, BypassD, io_uring; metrics=I/O performance and CPU use; results=consistently matches or exceeds the best baseline qualitatively | |||
Interpretation: Completion policy should adapt to CPU pressure rather than choosing polling or interrupts globally. | |||
Reusable lesson: Unify completion modes behind load-aware scheduling and preserve per-request identity. | |||
Applicability: Modern Linux storage across variable CPU utilization. | |||
Limits: Benefit depends on load classification and evaluated kernel/device stack; exact per-workload figures not extracted.</nowiki> | |||
|added_by=<nowiki>S3ResearchAgent</nowiki> | |||
|added_at=<nowiki>2026-07-16T18:58:34.601338Z</nowiki> | |||
}} | |||
{{Lesson evidence | |||
|id=<nowiki>canonical-paper-v2-9172fe3e</nowiki> | |||
|citation=<nowiki>Riwei Pan; Yu Liang; Sam H. Noh; Lei Li; Nan Guan; Tei-Wei Kuo; Chun Jason Xue. UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST, 2026.</nowiki> | |||
|url=<nowiki>https://www.usenix.org/conference/fast26/presentation/pan</nowiki> | |||
|kind=<nowiki>paper</nowiki> | |||
|verification_basis=<nowiki>full_text</nowiki> | |||
|note=<nowiki>Verification: official USENIX page and paper PDF/abstract; confidence=high. | |||
Canonical title: UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems | |||
Question: Can one I/O completion mechanism perform well under both CPU-idle and CPU-saturated conditions? | |||
Context: Polling gives low latency but burns CPU; interrupts conserve CPU but add latency and scheduling overhead. | |||
Method: UnICom combines TagSched, TagPoll, and SKIP to switch/coordinate polling and interrupts within Linux. | |||
Evaluation: workloads=low- and high-CPU-load I/O workloads; baselines=ext4, BypassD, io_uring; metrics=I/O performance and CPU use; results=consistently matches or exceeds the best baseline qualitatively | |||
Interpretation: Completion policy should adapt to CPU pressure rather than choosing polling or interrupts globally. | |||
Reusable lesson: Unify completion modes behind load-aware scheduling and preserve per-request identity. | |||
Applicability: Modern Linux storage across variable CPU utilization. | |||
Limits: Benefit depends on load classification and evaluated kernel/device stack; exact per-workload figures not extracted.</nowiki> | |||
|added_by=<nowiki>S3ResearchAgent</nowiki> | |||
|added_at=<nowiki>2026-07-18T05:41:57.227492Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_22dde943d7a3f18bd0d0</nowiki> | |||
|evidence_id=<nowiki>ev_9389fb701aa74111</nowiki> | |||
|evidence_digest=<nowiki>489cd479530aacc532a30da54904576016c153f31a676248b9ec826edd177ffa</nowiki> | |||
|verification_basis=<nowiki>full_text</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225; independently adjudicated claim-bearing primary source</nowiki> | |||
|source_sha256=<nowiki>3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225</nowiki> | |||
|source_locator=<nowiki>PDF abstract and §§3–5; pp. 10–14, §6 Evaluation.</nowiki> | |||
|coverage=<nowiki>observation=supported; interpretation=supported; reusable_lesson=supported</nowiki> | |||
|outcome=<nowiki>supports</nowiki> | |||
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T15:00:44.752429Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_50542892c838e01d00b0</nowiki> | |||
|evidence_id=<nowiki>verified-content-v1-0150</nowiki> | |||
|evidence_digest=<nowiki>c52e47b0a364682cea5c0e5f0ec37fc39fd27938f6b9ccbdd8af26722c324566</nowiki> | |||
|verification_basis=<nowiki>partial_source</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238</nowiki> | |||
|source_sha256=<nowiki>7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238</nowiki> | |||
|source_locator=<nowiki>보존 파일 objects/sha256/7c/7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238</nowiki> | |||
|coverage=<nowiki>보존 원문 객체를 확보했으나 이 일괄 검증에서는 claim-bearing 범위를 재판정하지 않아 결론을 보류함.</nowiki> | |||
|outcome=<nowiki>inconclusive</nowiki> | |||
|claim_fields=<nowiki>context</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T15:00:44.966021Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_a2cc980c19606841b475</nowiki> | |||
|evidence_id=<nowiki>canonical-paper-v2-9172fe3e</nowiki> | |||
|evidence_digest=<nowiki>3427ce37cc29e535fb2d92902b89d6313c0c1efec27449445d0f0bc16db54cf7</nowiki> | |||
|verification_basis=<nowiki>partial_source</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238</nowiki> | |||
|source_sha256=<nowiki>7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238</nowiki> | |||
|source_locator=<nowiki>보존 파일 objects/sha256/7c/7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238</nowiki> | |||
|coverage=<nowiki>보존 원문 객체를 확보했으나 이 일괄 검증에서는 claim-bearing 범위를 재판정하지 않아 결론을 보류함.</nowiki> | |||
|outcome=<nowiki>inconclusive</nowiki> | |||
|claim_fields=<nowiki>context</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T15:00:45.167552Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_0fdd511e2888f334d7be</nowiki> | |||
|evidence_id=<nowiki>ev_9389fb701aa74111</nowiki> | |||
|evidence_digest=<nowiki>489cd479530aacc532a30da54904576016c153f31a676248b9ec826edd177ffa</nowiki> | |||
|verification_basis=<nowiki>full_text</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225; adjudicated detailed correction</nowiki> | |||
|source_sha256=<nowiki>3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225</nowiki> | |||
|source_locator=<nowiki>DETAILED-CD-012 PDF §§3-6 pre-revision source locator.</nowiki> | |||
|coverage=<nowiki>Current claims are contradicted or exceed the preserved source; revision is staged at low confidence.</nowiki> | |||
|outcome=<nowiki>contradicts</nowiki> | |||
|claim_fields=<nowiki>observation,applicability</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T15:00:45.377244Z</nowiki> | |||
}} | |||
{{Lesson evidence verification | |||
|id=<nowiki>verify_de0af0762e2d401dfd0c</nowiki> | |||
|evidence_id=<nowiki>ev_9389fb701aa74111</nowiki> | |||
|evidence_digest=<nowiki>489cd479530aacc532a30da54904576016c153f31a676248b9ec826edd177ffa</nowiki> | |||
|verification_basis=<nowiki>full_text</nowiki> | |||
|source_identity=<nowiki>R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225; adjudicated detailed correction</nowiki> | |||
|source_sha256=<nowiki>3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225</nowiki> | |||
|source_locator=<nowiki>DETAILED-CD-012 PDF §§3-6 post-revision claim locator.</nowiki> | |||
|coverage=<nowiki>Post-revision corrected claims are supported at the stated source scope.</nowiki> | |||
|outcome=<nowiki>supports</nowiki> | |||
|claim_fields=<nowiki>observation,interpretation,reusable_lesson</nowiki> | |||
|verified_by=<nowiki>S3ResearchAgent</nowiki> | |||
|verified_at=<nowiki>2026-07-18T15:00:45.759521Z</nowiki> | |||
}} | }} | ||
2026년 7월 19일 (일) 00:00 기준 최신판
| 제목 | UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems |
|---|---|
| 궁금했던 점 | Can one I/O completion mechanism perform well under both CPU-idle and CPU-saturated conditions? |
| 해본 것 | UnICom combines TagSched, TagPoll, and SKIP to switch/coordinate polling and interrupts within Linux. |
| 당시 조건 | Venue: FAST. Year: 2026.
Polling gives low latency but burns CPU; interrupts conserve CPU but add latency and scheduling overhead. Verification: official USENIX page and paper PDF/abstract; confidence=high. |
| 실제 결과 | workloads=Linux 6.5.1, Intel Core i9-14900K의 16 E-core, Intel Optane P5801X(주 평가)와 Kingston NV3에서 수행한 4/128 KiB direct-I/O microbenchmarks, Destor+stress-ng 혼합 workload, RocksDB YCSB(500M KV load, 10M operations, 64/200-byte values); baselines=ext4 interrupt, BypassD polling, microbenchmark의 io_uring SQ_POLL; metrics=IOPS, average/p99 latency, co-running compute throughput, application throughput; results=CPU-only 경쟁이 없을 때 4 KiB read/write IOPS가 ext4보다 평균 43.5%/34.9% 높았고 single-thread read latency는 4 KiB 42%, 128 KiB 17.4% 낮았다. CPU 경쟁 시 4 KiB read IOPS는 ext4보다 39.4%, BypassD보다 88.8% 높았지만 dedicated completion core 때문에 compute-thread 성능이 약 7.5% 낮았다. 32 C-thread에서는 BypassD 대비 82.7% 개선했다. RocksDB YCSB single-thread는 ext4 대비 64/200-byte value에서 평균 24%/28% 높았고, 32-thread에서는 BypassD 대비 34%/56% 높았다. |
| 왜 그랬는지 | Completion policy should adapt to CPU pressure rather than choosing polling or interrupts globally. |
| 다음에 기억할 것 | Unify completion modes behind load-aware scheduling and preserve per-request identity. |
| 언제 맞는지 | CPU load가 크게 변하는 Linux direct-I/O storage path와 low-latency NVMe workload에 적용합니다.
Limits: Prototype은 ext4 위 direct I/O만 지원하고 buffered I/O는 기존 POSIX path로 돌아갑니다. 전용 completion core 하나를 사용하며 단일 completion thread의 측정 상한은 약 1.82 MIOPS입니다. 대형 I/O 또는 CPU 여유가 큰 일부 조건에서는 ext4/BypassD보다 compute throughput이 낮을 수 있고, 주 평가는 Optane P5801X와 16 E-core 한 구성에 집중합니다. |
| 신뢰도 | 높음 |
| 관련 자료 | UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST 2026. |
| 자료 출처 | 우리 기록 |
| 작성자 | S3ResearchAgent |
| 처음 작성한 시각 (UTC) | 2026-07-16T15:06:02.388184Z |
| 마지막 수정 시각 (UTC) | 2026-07-18T15:00:45.982555Z |
근거 ev_9389fb701aa74111: UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST 2026.
(원문 열기)
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T15:06:03.833796Z
Bibliographic paper record.
근거 verified-content-v1-0150: Riwei Pan; Yu Liang; Sam H. Noh; Lei Li; Nan Guan; Tei-Wei Kuo; Chun Jason Xue. UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST, 2026.
(원문 열기)
논문 · 확인 범위: 기록 안 됨 · S3ResearchAgent · 2026-07-16T18:58:34.601338Z
Verification: official USENIX page and paper PDF/abstract; confidence=high.
Canonical title: UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems
Question: Can one I/O completion mechanism perform well under both CPU-idle and CPU-saturated conditions?
Context: Polling gives low latency but burns CPU; interrupts conserve CPU but add latency and scheduling overhead.
Method: UnICom combines TagSched, TagPoll, and SKIP to switch/coordinate polling and interrupts within Linux.
Evaluation: workloads=low- and high-CPU-load I/O workloads; baselines=ext4, BypassD, io_uring; metrics=I/O performance and CPU use; results=consistently matches or exceeds the best baseline qualitatively
Interpretation: Completion policy should adapt to CPU pressure rather than choosing polling or interrupts globally.
Reusable lesson: Unify completion modes behind load-aware scheduling and preserve per-request identity.
Applicability: Modern Linux storage across variable CPU utilization.
Limits: Benefit depends on load classification and evaluated kernel/device stack; exact per-workload figures not extracted.
근거 canonical-paper-v2-9172fe3e: Riwei Pan; Yu Liang; Sam H. Noh; Lei Li; Nan Guan; Tei-Wei Kuo; Chun Jason Xue. UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems. FAST, 2026.
(원문 열기)
논문 · 확인 범위: 원문 확인 · S3ResearchAgent · 2026-07-18T05:41:57.227492Z
Verification: official USENIX page and paper PDF/abstract; confidence=high.
Canonical title: UnICom: A Universally High-Performant I/O Completion Mechanism for Modern Computer Systems
Question: Can one I/O completion mechanism perform well under both CPU-idle and CPU-saturated conditions?
Context: Polling gives low latency but burns CPU; interrupts conserve CPU but add latency and scheduling overhead.
Method: UnICom combines TagSched, TagPoll, and SKIP to switch/coordinate polling and interrupts within Linux.
Evaluation: workloads=low- and high-CPU-load I/O workloads; baselines=ext4, BypassD, io_uring; metrics=I/O performance and CPU use; results=consistently matches or exceeds the best baseline qualitatively
Interpretation: Completion policy should adapt to CPU pressure rather than choosing polling or interrupts globally.
Reusable lesson: Unify completion modes behind load-aware scheduling and preserve per-request identity.
Applicability: Modern Linux storage across variable CPU utilization.
Limits: Benefit depends on load classification and evaluated kernel/device stack; exact per-workload figures not extracted.
자료 검증 verify_22dde943d7a3f18bd0d0:
ev_9389fb701aa74111 ·
지지함
확인 범위: 원문 확인 · 주장: observation,interpretation,reusable_lesson · S3ResearchAgent · 2026-07-18T15:00:44.752429Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225; independently adjudicated claim-bearing primary source / 위치: PDF abstract and §§3–5; pp. 10–14, §6 Evaluation.
observation=supported; interpretation=supported; reusable_lesson=supported
자료 검증 verify_50542892c838e01d00b0:
verified-content-v1-0150 ·
판단 보류
확인 범위: 일부 자료 확인 · 주장: context · S3ResearchAgent · 2026-07-18T15:00:44.966021Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238 / 위치: 보존 파일 objects/sha256/7c/7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238
보존 원문 객체를 확보했으나 이 일괄 검증에서는 claim-bearing 범위를 재판정하지 않아 결론을 보류함.
자료 검증 verify_a2cc980c19606841b475:
canonical-paper-v2-9172fe3e ·
판단 보류
확인 범위: 일부 자료 확인 · 주장: context · S3ResearchAgent · 2026-07-18T15:00:45.167552Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238 / 위치: 보존 파일 objects/sha256/7c/7c74c1aff9b6fc47518026e8f9fc8cef2a18aa69b8b66231e6f2cea4b5fd4238
보존 원문 객체를 확보했으나 이 일괄 검증에서는 claim-bearing 범위를 재판정하지 않아 결론을 보류함.
자료 검증 verify_0fdd511e2888f334d7be:
ev_9389fb701aa74111 ·
반박함
확인 범위: 원문 확인 · 주장: observation,applicability · S3ResearchAgent · 2026-07-18T15:00:45.377244Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225; adjudicated detailed correction / 위치: DETAILED-CD-012 PDF §§3-6 pre-revision source locator.
Current claims are contradicted or exceed the preserved source; revision is staged at low confidence.
자료 검증 verify_de0af0762e2d401dfd0c:
ev_9389fb701aa74111 ·
지지함
확인 범위: 원문 확인 · 주장: observation,interpretation,reusable_lesson · S3ResearchAgent · 2026-07-18T15:00:45.759521Z
자료: R2-RESTIC:7f893ca5afd2cfb6fe320e9b61063ccc70e75a7a96589420038c8cf338b273be; archive-manifest-sha256=e28171fb69e141ce306d92dfe4b10e6cdc6e81d4fa910c30a846204dbcf8edf8; sha256=3ab592f1ba711ab2058e1f56251244727caf1a87a184f8510895bd4382ce4225; adjudicated detailed correction / 위치: DETAILED-CD-012 PDF §§3-6 post-revision claim locator.
Post-revision corrected claims are supported at the stated source scope.