You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We noticed that the latency value seems to be calculated by the command block size parameter instead of the number of bytes that actually got written/read. We ran a few sample commands here. We ran IOR with -t 1G and block size of 10G, 100G, 1000G, 10000G, and 100000G. Each latency value seemed to decrease inversely by the same factor of 10. The code for latency calculation also seems to use the parameter size and not the size of what was actually read/written.
Should the actual number of bytes be used in latency calculation, or is there a field that does this?
Example Test Runs with minimum output:
[root@client]# cat /tmp/ior-easy-results/ior-easy-write-summary.txt
IOR-3.4.0+dev: MPI Coordinated Test of Parallel I/O
Began : Sat Jun 29 00:09:43 2024
Command line : /opt/io500-sc22/bin/ior -e -k -O summaryFile=/tmp/ior-easy-results/ior-easy-write-summary.txt -O saveRankPerformanceDetailsCSV=/tmp/ior-easy-results/ior-easy-write.csv -t 1G -b 10G -s 1 -o /mnt/mnt/ior-easy -a POSIX -w -F --dataPacketType=timestamp -C -Q 1 -g -G 1719619473 -D 60 -O stoneWallingWearOut=1 -O stoneWallingStatusFile=/tmp/ior-easy-results/ior-easy.stonewall
Latency(s)
----------
0.778828
[root@client]# cat /tmp/ior-easy-results/ior-easy-write-summary.txt
IOR-3.4.0+dev: MPI Coordinated Test of Parallel I/O
Began : Sat Jun 29 00:10:14 2024
Command line : /opt/io500-sc22/bin/ior -e -k -O summaryFile=/tmp/ior-easy-results/ior-easy-write-summary.txt -O saveRankPerformanceDetailsCSV=/tmp/ior-easy-results/ior-easy-write.csv -t 1G -b 100G -s 1 -o /mnt/mnt/ior-easy -a POSIX -w -F --dataPacketType=timestamp -C -Q 1 -g -G 1719619473 -D 60 -O stoneWallingWearOut=1 -O stoneWallingStatusFile=/tmp/ior-easy-results/ior-easy.stonewall
Latency(s)
0.603770
[root@client]# cat /tmp/ior-easy-results/ior-easy-write-summary.txt
IOR-3.4.0+dev: MPI Coordinated Test of Parallel I/O
Began : Sat Jun 29 00:11:51 2024
Command line : /opt/io500-sc22/bin/ior -e -k -O summaryFile=/tmp/ior-easy-results/ior-easy-write-summary.txt -O saveRankPerformanceDetailsCSV=/tmp/ior-easy-results/ior-easy-write.csv -t 1G -b 1000G -s 1 -o /mnt/mnt/ior-easy -a POSIX -w -F --dataPacketType=timestamp -C -Q 1 -g -G 1719619473 -D 60 -O stoneWallingWearOut=1 -O stoneWallingStatusFile=/tmp/ior-easy-results/ior-easy.stonewall
Results:
Latency(s)
0.060289
[root@client]# cat /tmp/ior-easy-results/ior-easy-write-summary.txt
IOR-3.4.0+dev: MPI Coordinated Test of Parallel I/O
Began : Sat Jun 29 00:13:25 2024
Command line : /opt/io500-sc22/bin/ior -e -k -O summaryFile=/tmp/ior-easy-results/ior-easy-write-summary.txt -O saveRankPerformanceDetailsCSV=/tmp/ior-easy-results/ior-easy-write.csv -t 1G -b 10000G -s 1 -o /mnt/mnt/ior-easy -a POSIX -w -F --dataPacketType=timestamp -C -Q 1 -g -G 1719619473 -D 60 -O stoneWallingWearOut=1 -O stoneWallingStatusFile=/tmp/ior-easy-results/ior-easy.stonewall
Results:
Latency(s)
0.006072
[root@client]# cat /tmp/ior-easy-results/ior-easy-write-summary.txt
IOR-3.4.0+dev: MPI Coordinated Test of Parallel I/O
Began : Sat Jun 29 00:14:59 2024
Command line : /opt/io500-sc22/bin/ior -e -k -O summaryFile=/tmp/ior-easy-results/ior-easy-write-summary.txt -O saveRankPerformanceDetailsCSV=/tmp/ior-easy-results/ior-easy-write.csv -t 1G -b 100000G -s 1 -o /mnt/mnt/ior-easy -a POSIX -w -F --dataPacketType=timestamp -C -Q 1 -g -G 1719619473 -D 60 -O stoneWallingWearOut=1 -O stoneWallingStatusFile=/tmp/ior-easy-results/ior-easy.stonewall
Results:
Latency(s)
0.000607
The text was updated successfully, but these errors were encountered:
dbishop
added a commit
to dbishop/ior
that referenced
this issue
Jan 18, 2025
Fixeshpc#495
Each task computes its average operation latency by dividing its
(RDWR_STOP - RCWR_START) delta-t by the number of operations performed.
Without stonewalling, the denominator is a constant and known a priori.
But with stonewalling, the task's actual IOs issued should be used
instead. That's already available in point->pairs_accessed.
Hi there!
We noticed that the latency value seems to be calculated by the command block size parameter instead of the number of bytes that actually got written/read. We ran a few sample commands here. We ran IOR with
-t 1G
and block size of 10G, 100G, 1000G, 10000G, and 100000G. Each latency value seemed to decrease inversely by the same factor of 10. The code for latency calculation also seems to use the parameter size and not the size of what was actually read/written.Should the actual number of bytes be used in latency calculation, or is there a field that does this?
Example Test Runs with minimum output:
The text was updated successfully, but these errors were encountered: