J95D / namebench

Automatically exported from code.google.com/p/namebench
Apache License 2.0
0 stars 0 forks source link

range() integer step argument expected, got NoneType (time moves backwards) #130

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1.Start it with the settings shown in the attached picture

What is the expected output? What do you see instead?
I don't know it has never worked for me before.

What version of the product are you using? On what operating system?
Latest, WindowsXP SP3. 

Please provide any additional information below.
I don't know what is relevant, ask me for details if you need some. The
settings i used and the error i got are in the attached image.

Original issue reported on code.google.com by VinceVri...@gmail.com on 5 Jun 2010 at 4:22

Attachments:

GoogleCodeExporter commented 8 years ago
Thanks for the bug report and screenshot. I think I have fixed the bug in r985 
- can you download 1.3.1-RC1 to 
see if it works properly for you?

http://namebench.googlecode.com/files/namebench-1.3.1-RC1-Windows.exe

Thanks!

Original comment by helixblue on 5 Jun 2010 at 5:03

GoogleCodeExporter commented 8 years ago
I got another error but this one is probably a typo in the script. 

Original comment by VinceVri...@gmail.com on 5 Jun 2010 at 5:45

Attachments:

GoogleCodeExporter commented 8 years ago
Sorry about that. Does 1.3.1-RC2 work any better? 
http://code.google.com/p/namebench/downloads/list

Original comment by helixblue on 5 Jun 2010 at 6:19

GoogleCodeExporter commented 8 years ago
I just tried RC3 as that was the latest one when i looked. It did work without
raising an error now. I got odd results tough. Everything timed out on every 
DNS. I
attached the results html page. The uploaded public result page
(http://namebench.appspot.com/id/553005) also spits out the following python 
error:

Traceback (most recent call last):
  File
"/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__
.py",
line 511, in __call__
    handler.get(*groups)
  File "/base/data/home/apps/namebench/3.342383898571905264/lookup.py", line 71, in get
    'min_duration_url': self._CreateMinimumDurationUrl(nsdata, key="min-%s" % id),
  File "/base/data/home/apps/namebench/3.342383898571905264/lookup.py", line 123, in
_CreateMinimumDurationUrl
    url = charts.MinimumDurationBarGraph(min_data)
  File "/base/data/home/apps/namebench/3.342383898571905264/libnamebench/charts.py",
line 131, in MinimumDurationBarGraph
    labels = range(0, scale, tick) + [scale]
TypeError: range() integer step argument expected, got NoneType.

Original comment by VinceVri...@gmail.com on 5 Jun 2010 at 10:50

Attachments:

GoogleCodeExporter commented 8 years ago
Given your earlier error, I did expect some strange results, but nothing like 
this. I've updated the 
namebench.appspot.com website with the same code so that it no longer crashes 
as well. It may seem 
unbelievable, but the results show that Python thinks the clock on your 
computer is moving backwards 
sometimes rather than forwards. 

Does your computer have multiple cores or processors? If so, I bet we are 
running into this quirk in Windows: 
http://www.virtualdub.org/blog/pivot/entry.php?id=106

Can you run this command from a command-line for me - I am curious what the 
output looks like:

ping 192.168.1.1

I may try to put a workaround in place that we detect this kind of issue, and 
switch to a less accurate time 
source. Thinking it through now.

Original comment by helixblue on 6 Jun 2010 at 6:55

GoogleCodeExporter commented 8 years ago
I've implemented a workaround in 1.3.1-RC4 that I would like you to test if 
possible:

http://code.google.com/p/namebench/downloads/list

I've added some detection to see if the high-precision clock appears to be 
going backwards, and if so, switch to a 
lower precision version. I'm not fully certain this technique works well, so I 
am eager to see what it does for you.

Original comment by helixblue on 6 Jun 2010 at 7:37

GoogleCodeExporter commented 8 years ago
Sometimes it returns a negative ping, i got: -12ms, 14ms, 15ms and -15ms. I 
looked it
up a while ago and it's because of my AMD processor. I have an AMD Athlon X2 
3800. 

I just tried RC4, got another error, see the attachment. I will be leaving this
computer in 3 hours and i will not come back before 2 weeks, so i won't be able 
to
test for a while.

Original comment by VinceVri...@gmail.com on 6 Jun 2010 at 9:20

Attachments:

GoogleCodeExporter commented 8 years ago
Thanks again for the feedback! I've posted RC5, which tries to improve the 
detection of whether to use 
time.clock() or time.time() by inserting micro-sleeps in between calls. Once it 
has selected an appropriate 
clock to use, if it ever encounters a negative time, it will crash loudly with:

BrokenSystemClock('The time on your machine appears to be going backwards. '
                              'We cannot accurately benchmark due to this error. '
                              '(timer=%s, duration=%s)' % (self.timer, duration))

If you get a chance, I'm curious to see if it makes any difference. If you get 
the BrokenSystemClock message, I 
am curious to see which timer it says it is using. 

From further research, I found http://wiki.ljackson.us/Negative_Ping_Time which 
mentions that AMD posted a 
fix for this issue for Windows XP and Windows 2003 users. To download it, go to:

http://www.amd.com/us-en/Processors/TechnicalResources/0,,30[_]182[_]871[_]13118
,00.html

Search the page for: AMD Athlon™ 64 X2 Dual Core Processor Driver for Windows 
XP and Windows Server 2003 
Version (x86 and x64 exe) 1.3.2.16 

Original comment by helixblue on 6 Jun 2010 at 10:30

GoogleCodeExporter commented 8 years ago
I just tried RC5 WITHOUT the processor fix. This is the reulst page. I have to 
go
now, I'll try the fix in 2 weeks.

Original comment by VinceVri...@gmail.com on 6 Jun 2010 at 11:47

GoogleCodeExporter commented 8 years ago
This should be fixed as of 1.3.1. It will now complain if time goes backwards 
consistently. 

Original comment by helixblue on 15 Jul 2010 at 1:15