[更新376#2825]PECMD2012.1.80.13_Win32_64.多窗口多线程.裸机系统2.3.3.1+18M酷M...

2011hwo1

原帖由 mdyblog 于 2013-4-2 19:30 发表
HELP 支持 （循环）模糊搜索文本。如图
158862

HELP 支持模糊书签
   HELP CALCABC
   HELP CALXXX   都 对应  SWIN  


HELP 支持 模糊查询，直达某字符串
格式： HELP ~字符串[.]
.表示不表格对齐 ...

我电脑的时钟频率是3579545hz,你的电脑时钟的频率是2241044hz?
结果测试不关是uptime不准确,utc时间一样的是不准确率,大概是精确到15ms,不知道能不能让utc时间也能提高精度

2011hwo1

原帖由 mdyblog 于 2013-4-3 00:56 发表
以纳秒 为单位。 （10^-9秒)再 带3位小数。

这所的是Counter计数所代表的最小时间单位吗?
就我的电脑时钟的周期是3579545,也就是说1个时钟的周期是1/3579545=2.79e-7,就是27.9us,不可能精确到10^-9秒秒的,最多是2.79*10^-7秒
如果你的电脑时钟的周期是2241044那精度会更低的,为1/2241044=4.46e-7秒

2011hwo1

不知道utc时间的精度能提高吗

mdyblog

原帖由 2011hwo1 于 2013-4-3 13:42 发表

这所的是Counter计数所代表的最小时间单位吗?
就我的电脑时钟的周期是3579545,也就是说1个时钟的周期是1/3579545=2.79e-7,就是27.9us,不可能精确到10^-9秒秒的,最多是2.79*10^-7秒
如果你的电脑时钟的周期是 ...

是 4.46e-7秒

只是 为了输出 易理解的 单位， 只能 us ns 皮s

实际进度和计算机发展有关， 所以选一个 小点的单位， 能多用一段时间。 如此而已。

2011hwo1

utc时间只能精确到15ms,uptime大概精确度也是15ms,不知道能提高精度吗

mdyblog

原帖由 2011hwo1 于 2013-4-3 13:42 发表
不知道utc时间的精度能提高吗

UTC 只是个标准形式， 以0.1us为单位。 实际的数值， 取决于计算机系统。
精度高不过 Counter 。
也别太计较了。 windwos 是非实时系统。 一个系统调用， 可能都要1us,  因此 就这样吧。
一次任务调度 引起 的误差 好多ms.

最准的就是Counter 了。


UTC 和uptime  用的是   软件系统的值。
系统软件的值， 精度为 1ms (或10ms ).
远不及  Counter 。 Counter  可达 0.5us。

[ 本帖最后由 mdyblog 于 2013-4-3 14:26 编辑 ]

mdyblog

原帖由 2011hwo1 于 2013-4-3 13:56 发表
utc时间只能精确到15ms,uptime大概精确度也是15ms,不知道能提高精度吗

》》 utc时间只能精确到15ms,uptime大概精确度也是15ms
怎么测出来的？

2011hwo1

就是多次运行date utc uptime命令来查看变化,可以得出
_sub b1
date a3 %1
_end
date a1 utc
date a2 uptime
set a=0
set b=0
loop %a%=0,team call b1 utc|calc #a=(%a3%-%a1%)/10
loop %b%=0,team call b1 uptime|calc b=%a3%-%a2%
mess utc精度为%a%us\nuptime精度为%b%ms
//utc精度为15625us
//uptime精度为15ms

2011hwo1

upc和uptime精度为1/64秒

mdyblog

原帖由 2011hwo1 于 2013-4-3 14:50 发表
upc和uptime精度为1/64秒

utc和uptime 没这么粗糙， 用VC测试， 都是1ms精度。

你的测试程序 太复杂。 中间主要是 程序运行时间和整个系统运行时间。

UTC  已改为COUNTER 来实现，可达 0.5us精度（实际Counter决定）。
uptime  本来单位就为1ms ，受此限制, 所以提高不了。
为此增加了  uptimens  ,单位为ns.  可达 0.5us精度（实际Counter决定）。

脚本中达不到本来精度间隔，因为中间还有运行时间。     但作为计时刻度， 精度还是高的好。

mdyblog

原帖由 2011hwo1 于 2013-4-3 14:50 发表
upc和uptime精度为1/64秒

测试如下：
// utc精度为4.5us 平均4us
// uptime精度为1000us 平均0.0036ms 3.6us //实际很多 0 ,平均4us
// uptimens精度为4.016us 平均4.266114us

//旧版测试：
// utc精度为1000us 平均5us               //精度1ms
// uptime精度为16000us 平均0.008ms 7.8us //精度16ms 大概1/64秒

time_test.WCS：
//LOGS *X.log
TEAM ENVI^ ENVIMODE=1| ENVI^ FORCELOCAL=1
_sub Tutc *
   date a3 utc
   date a4 utc
   CALC  #e= %a4% - %a3%
   IFEX $%e%>0, IFEX $%e%<%m%, SET m=%e%  //取最小非0时间
   CALC  #d= %e% + %d%
_end
_sub Tuptime *
   date a3 uptime
   date a4 uptime
   CALC  #e= %a4% - %a3%
   IFEX $%e%>0, IFEX $%e%<%m%, SET m=%e%  //取最小非0时间
   CALC  #d= %e% + %d%
_end

_sub Tuptimens *
   date a3 uptimens
   date a4 uptimens
   CALC  #e= %a4% - %a3%  
   IFEX $%e%>0, IFEX $%e%<%m%, SET m=%e%  //取最小非0时间
   CALC  #d= %e% + %d%
_end

SET &a=| SET &d=| SET &a3=| SET &a4=| SET &m=| SET &e=

TEAM set d=0| set a=10000| SET m=999999999
loop #%a%>0,team call Tutc  | CALC #a=%a% - 1
CALC jam=%m%  / 10#01
CALC #ja= %d% / 100000   //0.1us=>us

TEAM set d=0| set a=10000| SET m=9999999999
loop #%a%>0,team call Tuptime | CALC #a=%a% - 1
CALC jbm=%m% * 1000
CALC jbus= %d% / 10##01   //ms=>us
CALC jbms= %d% / 10000##04   //ms

TEAM set d=0| set a=10000| SET m=9999999999
loop #%a%>0,team call Tuptimens | CALC #a=%a% - 1
CALC jcm=%m%  / 1000##03
CALC jc= %d%   / 10000000##06   //ns=>us

mess  utc精度为%jam%us  平均%ja%us  \n uptime精度为%jbm%us 平均%jbms%ms %jbus%us  \n uptimens精度为%jcm%us  平均%jc%us   


[ 本帖最后由 mdyblog 于 2013-4-4 02:08 编辑 ]

2011hwo1

原帖由 mdyblog 于 2013-4-3 16:10 发表

测试如下：
// utc精度为4.5us 平均4us
// uptime精度为1000us 平均0.004ms 3.6us //实际很多 0 ,平均4us
// uptimens精度为4.016us 平均4.266114us

//旧版测试：
// utc精度为1000us 平均5us       ...

经过测试得到:
旧版:
utc精度为15625us  平均15us  
uptime精度为0us 平均156.250ms 156250.0us
新版
utc精度为11.5us  平均12us  
uptime精度为1000us 平均0.011ms 11.4us
uptimens精度为13.409us  平均13.523842us

2011hwo1

原帖由 mdyblog 于 2013-4-3 16:10 发表

测试如下：
// utc精度为4.5us 平均4us
// uptime精度为1000us 平均0.004ms 3.6us //实际很多 0 ,平均4us
// uptimens精度为4.016us 平均4.266114us

//旧版测试：
// utc精度为1000us 平均5us       ...

IFEX $%e%>%m, SET m=%e%
应该是IFEX $%e%>%m%, SET m=%e%吧
新版测试结果为:
utc精度为588.1us  平均11us  
uptime精度为1000us 平均0.012ms 12.2us
uptimens精度为522.133us  平均13.999964us
旧版结果为:
utc精度为15625us  平均20us  
uptime精度为0us 平均203.125ms 203125.0us
uptimens精度为0.000us  平均0.203125us

mdyblog

原帖由 2011hwo1 于 2013-4-3 17:58 发表

IFEX $%e%>%m, SET m=%e%
应该是IFEX $%e%>%m%, SET m=%e%吧
新版测试结果为:
utc精度为588.1us  平均11us  
uptime精度为1000us 平均0.012ms 12.2us
uptimens精度为522.133us  平均13.999964us
旧 ...

是的， 上面已改了。
要多测几次， 再最小结果， 就是 实际精度。 上面已经取了1000次的最大值。 所以多测几次，再取最小值。
这样出去系统的干扰。
中间碰到系统的任务切换、磁盘调度、内存调度，中间插入别的任务， 就会变得很大， 1000次碰到一次的几率不小啊。 很大的值基本上都忽略掉，再测。
测得：
utc精度为23.6us  平均4us  
uptime精度为1000us 平均0.004ms 3.6us  
uptimens精度为18.295us  平均4.254294us
估计在PE下测试， 稳定点。没那么多调度的。

[ 本帖最后由 mdyblog 于 2013-4-3 18:12 编辑 ]

mdyblog

DATE 加了个 *us 开关 在毫秒后加4为小数。达到UTC 的精度
date *us *space &V
MESS %&V%
// 2013 4 3 3 18 15 41 342.0130

2011hwo1

结果测试:calc #运行一次计算最少100us calc运行一次计算最少140us

2011hwo1

现在实验了下好像原来的date获得的时间只要是刷新慢,精度基本上还是够的,刷新时间为1/64秒

mdyblog

原帖由 2011hwo1 于 2013-4-3 18:28 发表
现在实验了下好像原来的date获得的时间只要是刷新慢,精度基本上还是够的,刷新时间为1/64秒

“刷新慢” 是什么意思？  和精度 什么关系？

2011hwo1

就是好像被系统限制了每秒去系统时间的次数一样,如果连续取系统时间就在一定时间内不更新取出来的时间,而返回原来的时间,导致精度表面上看起来精度不高,就是date 变量名 获得的时间都有同样的问题

2011hwo1

曾经用易语言获得时间也有同样的问题,大概是那个函数只能在第一次刷新了后要等1/64秒才刷新吧

mdyblog

原帖由 2011hwo1 于 2013-4-3 19:14 发表
就是好像被系统限制了每秒去系统时间的次数一样,如果连续取系统时间就在一定时间内不更新取出来的时间,而返回原来的时间,导致精度表面上看起来精度不高,就是date 变量名 获得的时间都有同样的问题

这么说就是 精度了。
基本精度1T， 每N个T才更新一次， 那个这个 计时器的精度就是N*T.

mdyblog

原帖由 2011hwo1 于 2013-4-3 18:19 发表
结果测试:calc #运行一次计算最少100us calc运行一次计算最少140us

CALC #a=1 + 1**
11.20us

//上下面数字是１２３４５　怎么半角的变成这个样? 坛子怎么了？ 换成13456吧。
TEAM ENVI &&&ENVIMODE=1| ENVI &&&FORCELOCAL=1
TEAM  SET-def T1=| SET-def T2=| SET-def a=
DATE T1   utc
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
CALC #a=1 + 13456
DATE T2   utc
CALC d=(%T2% - %T1%) / 20 / 10##02
MESS %d%us
//11.20us

[ 本帖最后由 mdyblog 于 2013-4-3 19:45 编辑 ]

2010qaqz111

精度和硬件时钟有关，非实时OS上的误差普遍比较大，Counter的精度在 windows 的应用来说够了，只是别拿 win 的机器去做精细的工业控制，一般的应用误差那么点点没有任何影响。

2011hwo1

原帖由 mdyblog 于 2013-4-3 19:28 发表


这么说就是 精度了。
基本精度1T， 每N个T才更新一次， 那个这个 计时器的精度就是N*T.

那的确也应该是算是精度的问题,新版就好得多了

527104427

请教一下老大：

C盘有一个批处理文件，C:\新建、&文件夹(4).bat

@echo off
PECMD.EXE LINK "%%SendTo%%\test","%~f0",,shell32.dll#4
pause

执行失败，要如何才能让它成功？

下面这句则可以：

PECMD.EXE FILE "%~f0"=^>"d:\%~nx0"

mdyblog

原帖由 527104427 于 2013-4-3 22:45 发表
请教一下老大：
C盘有一个批处理文件，C:\新建、&文件夹(4).bat
执行失败，要如何才能让它成功？
下面这句则可以：

1. PECMD.EXE "LINK %%SendTo%%\test,%~f0,,shell32.dll#4"
   
2. pause

复制代码

PECMD 有逗号分割的命令， 文件名都不需引号。
CMD 中碰到特殊字符， 可以将整个PECMD 命令 用引号 刮起来。 PECMD 执行前会先脱去引号。



FILE 命令最近改了， 有引号也没问题。

527104427

多谢老大指点，这句成功了：

PECMD.EXE "LINK %%SendTo%%\test,%~f0,,shell32.dll#4"

但是，下面这句失败：

PECMD.EXE "FILE %~f0=^>d:\%~nx0"

改回原来那种写法就没有问题：

PECMD.EXE FILE "%~f0"=^>"d:\%~nx0"

527104427

另外，百分号怎么写进注册表呢？

PECMD.EXE REGI HKCR\*\shell\expcab\command\="%~f0" "%%1"

实际上，HKCR\*\shell\expcab\command的值写错了，变成这样：

"C:\新建、&文件夹(4).bat" "REGI"

我的期望值是：

"C:\新建、&文件夹(4).bat" "%1"

mdyblog

原帖由 527104427 于 2013-4-3 23:24 发表
多谢老大指点，这句成功了：


但是，下面这句失败：


改回原来那种写法就没有问题：

两种方法重复了。

PECMD.EXE "FILE %~f0=>d:\%~nx0"
或
PECMD.EXE FILE %~f0=^>d:\%~nx0

mdyblog

原帖由 527104427 于 2013-4-3 23:47 发表
另外，百分号怎么写进注册表呢？
实际上，HKCR\*\shell\expcab\command的值写错了，变成这样：
我的期望值是：

1. PECMD.EXE REGI HKCR\*\shell\expcab\command\="%~f0" "%%%%1"

复制代码

PECMD2012 %1 会被解释的第一个参数REGI。 % 用%%表示。

CMD  解释"%%%%1" 为 "%%1"
PECMD2012 再解释为 "%1"