[Iometer-user] Re: [Fwd: [Iometer-devel] rdtsc]

[Ming Z. <mi...@el...>]

On Tue, 2005-07-26 at 15:41 +0100, Satinder Jeet Singh wrote:
> Hi Ming
>  
> Thanks for your suggestion.
> I have done experiment with this workaround (fixing low and high value
> of cpu frequency to same value cpuinfo_max_freq) and taken the io
> [performance data for different record sizes (from 512 Bytes to 4MB)
> and the results are now seems to be acceptable.
good to know.


>  
> But There is an observation that for all record sizes from 4KB to 4MB
> (4k, 16k, 64k, 256k, 512k, 1M, 2M, 4M) for sequential read/write the
> reading(Throughput)  are very close (such as 29.287, 29.0023,
> 28.659,.. so on).
what is u disk target? that is not a high number.


> Is this acceptable behaviour or there is still some problem with
> dynamo or cpu frequency.
>  
> Thanks & Regards,
> Satinder
>  
> 
> Ming Zhang <mi...@el...> wrote:
>         -------- Forwarded Message --------
>         > From: Ming Zhang 
>         > Reply-To: mi...@el...
>         > To: Daniel Scheibli 
>         > Cc: iometer-devel-list 
>         > Subject: [Iometer-devel] rdtsc
>         > Date: Tue, 05 Oct 2004 15:57:19 -0400
>         > Hi, Daniel
>         > 
>         > I wonder if we can add this as a temporary workaround for
>         that rdtsc
>         > under linux. If this is ok, i will check if windows has
>         similar
>         > workaround.
>         > 
>         > Our current solution is to read /proc/cpuinfo line "cpu
>         MHz : 1299.007"
>         > to decide processor speed and the cycles_per_sec. then use
>         this to
>         > convert rdtsc value difference to seconds.
>         > 
>         > Now we all know that it has problem since the frequency can
>         change from
>         > time to time. So there is a rdtsc skew. The low actual
>         running frequency
>         > will lead to a small rdtsc difference and then lead to
>         unrealistic high
>         > throughput number.
>         > 
>         > i originally want to use ACPI timers as the time source
>         since that one
>         > is always stable. But the main problem is that it is low
>         frequency. With
>         > more devices can get IOPS like 100K or 200K, it is
>         infeasible to use
>         > that.
>         > 
>         > I noticed that in linux, if you have cpufreq support, u can
>         get/set u
>         > freq from sysfs or proc (deprecated) interface. for example,
>         > 
>         > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
>         > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
>         > 
>         > decide the range of cpu frequency. if we set them to same
>         number, then
>         > it will fix cpu runtime frequency to a fix number.
>         > 
>         > so here is the workaround, since the number we get
>         from /proc/cpuinfo
>         > always equals to 
>         > 
>         > `cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq`
>         > 
>         > so we need to set both
>         > 
>         > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
>         > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
>         > 
>         > to the value in cpuinfo_max_freq
>         > 
>         > for system does not support sysfs, we can use /proc/cpufreq.
>         any modern
>         > kernel like 2.4.2x or 2.6.x support this.
>         > 
>         > any comment? 
>         > 
>         > i am not sure about other os.
>         > 
>         > if this is ok, we then need to decide whether we prepare a
>         script to do
>         > this or we add code in dynamo. i prefer a script.
>         > 
>         > ming
>         > 
>         
> 
> 
> ______________________________________________________________________
> How much free photo storage do you get? Store your friends n family
> photos for FREE with Yahoo! Photos. 
> http://in.photos.yahoo.com