colinux-users Mailing List for Cooperative Linux (Page 17)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Dear coLinux maintainers,
is there any way to mount cramfs images using the standard
coLinux-7.7.1 kernel ?

  Hello Ron,

CONFIG_HZ=100 is in coLinux Kernel config. This are 10 ms per jiffy. It 
does not matter, how often or in what time diff the function 
callback_return_jiffies is called on Windows side. The variable 
"timestamp_diff" will count the jiffies for the time coLinux was not active.

An other time base is a free running 100 ms timer (10Hz) for all coLinux 
daemons on Windows side. This intervall will wake up any sleeping 
Windows task for coLinux. So, we can guarantee, that coLinux will 
running all 100 ms in idle or more often in full running action.

Henry

On 03.09.2010 10:34, Ron Avriel wrote:
> Hi Henry,
>
> Can you please explain why you multiply by 100 in
>
> timestamp_diff += 100 * (((long long)timestamp.quad) - ((long 
> long)cmon->timestamp.quad)); /* HZ value */
>
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31
>
> If this function is called every 100ms, as you previously wrote, then 
> you get 10 jiffies per call. Shouldn't it be 1 jiffy per 100ms? 
> Shouldn't you multiply by 10 instead?
>
> I guess your calculation is right, but I can't figure it out.
>
> Thanks,
> Ron
>
> Date: Fri, 3 Sep 2010 00:42:47 +0200
> From: hen...@ar...
> To: ra...@ho...
> CC: col...@li...
> Subject: Re: [coLinux-users] Very large time offset in coLinux
>
> Hello Ron,
>
> we don't use RDTSC directly. We use windows API, and that should work 
> without problems. KeQueryPerformanceCounter is the only function with 
> smallest time interval. Of curse I also have seen updates for broken 
> KeQueryPerformanceCounter: http://support.microsoft.com/kb/896256
>
> The problem is not to follow the time. If the timediff is more as one 
> second, for example if you suspend Windows, then we set the time 
> absolutely. The problem is, from where we can get the exact time 
> stamp, if KeQueryPerformanceCounter is wrong?
>
> Here we have the two calculations. One on Windows side, here we 
> calculate the difference of "jiffies" in callback_return_jiffies:
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/kernel/monitor.c?view=markup#l366
>
> co_os_get_timestamp is here:
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31
>
> On Linux side we increment teh jiffies and time here in function 
> co_handle_jiffies:
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/base-2.6.33.diff?view=markup#l2563
>
> I will create more debug for cases of "time warps".
>
> --
> Henry

Have u looked at this http://support.microsoft.com/kb/274323. It mentions a method to check for jumps by comparing gettickcount and the results of queryperformancecounter. It reckons the problem is due to a fault in the south bridge.

Other sources say that the value returned can differ on each core in a multicore setup, avoided using an affinity mask

--
Sent from my Nokia N900

----- Original message -----
>
> Hi Shai,
>
> My Windows servers run with standard power options (always on, no
> hibernation).
>
> The frequency returned from QueryPerformanceFrequency "cannot change
> while the system is running" (from MSDN). If it did change then it could
> explain the problem, but since the Windows host is running OK, I assume
> that the root cause is different.
>
> Ron
>
> Date: Fri, 3 Sep 2010 12:43:04 +0300
> Subject: Re: [coLinux-users] Very large time offset in coLinux
> From: sva...@gm...
> To: hen...@ar...
> CC: ra...@ho...; col...@li...
>
> Hi Henry and Ron,
> Just to verify, I have duplicated this problem on my PC as well. This
> appears to be related to the selected Power Options settings (Control
> Panel, Power Options). I believe this can also happen if you have a
> variable frequency CPU as the time calculation is performed using
> QueryPerformanceCounter which counts CPU cycles and not time.
>
> Ron, can you verify this by disabling power options in your host?
> Thanks,
> - Shai
>
>

<Attachment>   ATT00001
<Attachment>   ATT00002

Hi Shai,

My Windows servers run with standard power options (always on, no hibernation).

The frequency returned from QueryPerformanceFrequency "cannot change while the system is running" (from MSDN). If it did change then it could explain the problem, but since the Windows host is running OK, I assume that the root cause is different.

Ron

Date: Fri, 3 Sep 2010 12:43:04 +0300
Subject: Re: [coLinux-users] Very large time offset in coLinux
From: sva...@gm...
To: hen...@ar...
CC: ra...@ho...; col...@li...

Hi Henry and Ron,
Just to verify, I have duplicated this problem on my PC as well.  This appears to be related to the selected Power Options settings (Control Panel, Power Options).  I believe this can also happen if you have a variable frequency CPU as the time calculation is performed using QueryPerformanceCounter which counts CPU cycles and not time.

Ron, can you verify this by disabling power options in your host?
Thanks,
- Shai

Had a few minutes.  Code I was thinking of was in Ogre3d. 

OgreTimer for Win32 has a section to compensate for PerformanceCounter leaps.  Might be worth checking out.

From: and...@ho...
To: sva...@gm...; hen...@ar...
Date: Fri, 3 Sep 2010 18:03:19 +0100
CC: col...@li...
Subject: Re: [coLinux-users] Very large time offset in coLinux

    Message body

I have seen some code to support the suggestion that it is down to the QueryPerformanceCounter and CPU scaling. I can't remember if it was in though. SFML, Ogre or Irrlicht are the most likely 

--

Sent from my Nokia N900

----- Original message -----

> Hi Henry and Ron,

> Just to verify, I have duplicated this problem on my PC as well. This

> appears to be related to the selected Power Options settings (Control

> Panel,

> Power Options). I believe this can also happen if you have a variable

> frequency CPU as the time calculation is performed using

> QueryPerformanceCounter which counts CPU cycles and not time.

> Ron, can you verify this by disabling power options in your host?

> Thanks,

> - Shai

> 

> On Fri, Sep 3, 2010 at 1:42 AM, Henry Nestler <hen...@ar...> wrote:

> 

> > Hello Ron,

> > 

> > we don't use RDTSC directly. We use windows API, and that should work

> > without problems. KeQueryPerformanceCounter is the only function with

> > smallest time interval. Of curse I also have seen updates for broken

> > KeQueryPerformanceCounter: http://support.microsoft.com/kb/896256

> > 

> > The problem is not to follow the time. If the timediff is more as one

> > second, for example if you suspend Windows, then we set the time

> absolutely.

> > The problem is, from where we can get the exact time stamp, if

> > KeQueryPerformanceCounter is wrong?

> > 

> > Here we have the two calculations. One on Windows side, here we

> calculate

> > the difference of "jiffies" in callback_return_jiffies:

> > 

> > 

> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/kernel/monitor.c?view=markup#l366

> > 

> > co_os_get_timestamp is here:

> > 

> > 

> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31

> > 

> > On Linux side we increment teh jiffies and time here in function

> > co_handle_jiffies:

> > 

> > 

> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/base-2.6.33.diff?view=markup#l2563

> > 

> > I will create more debug for cases of "time warps".

> > 

> > --

> > Henry

> > 

> > 

> > 

> > On 02.09.2010 13:06, Ron Avriel wrote:

> > 

> > Hi Henry and Shai,

> > 

> > Thanks for answers.

> > Here are some answers and more information:

> > 

> > The time always advanced to the future, so far.

> > In one coLinux it jumped forward 30944 seconds, and in another it

> jumped

> > more than 24 hours (I don't have the exact number).

> > The processor is an Intel Pentium 1.4 GHz.

> > QueryPerformanceFrequency on the server returns 3579545.

> > 

> > The problem already occurred several times on different servers, but

> it can

> > take days or weeks until it happens.

> > 

> > I think RDTSC is not a good idea for time measurement, because its

> speed

> > can change. Are you sure it's used in coLinux?

> > 

> > It seems to me that the problem is related to some wrong overflow

> > calculation. I'd check in that direction.

> > I also think that special handling is required if time difference

> between

> > coLinux wakeups is too large. Perhaps in that case you should get the

> real

> > time from Windows, like you do on startup?

> > 

> > Thanks,

> > Ron

> > 

> > Date: Thu, 2 Sep 2010 10:39:10 +0300

> > Subject: Re: [coLinux-users] Very large time offset in coLinux

> > From: sva...@gm...

> > To: hen...@ar...

> > CC: ra...@ho...; col...@li...

> > 

> > Hi Ron,

> > 

> > Do you use an AMD processor? If so, can you please be more specific,

> which

> > one? I *think* that this could be related to an issue I've seen with

> RDTSC

> > which reports the clock frequency, usually in accordance with

> > QueryPerformanceFrequency (could be a different API, not sure) but has

> some

> > problems with AMD processors. There should be a workaround, I'll have

> to dig

> > more into this.

> > Another option is that the RDTSC is not updated properly when the

> system is

> > in sleep (power maangement). Can you try again without power

> management

> > enabled and see if the issue is resolved?

> > 

> > Thanks,

> > 

> > - Shai

> > 

> > On Thu, Sep 2, 2010 at 2:42 AM, Henry Nestler <hen...@ar...>

> wrote:

> > 

> > On 01.09.2010 13:37, Ron Avriel wrote:

> > 

> > Hi,

> > 

> > I have several coLinux running in different Windows hosts.

> Occasionally,

> > the time in coLinux advances by several hours and up to a day!

> > The time on the Windows hosts always remains correct.

> > This happened on multiple coLinux servers, some of them ran NTP, but

> it

> > seems that NTP will not adjust clock if the offset is too large. It

> also

> > happened on a server that did not run NTP.

> > 

> > It should be noted that that the the large offset of 9 hours or more

> > happened at once. It's not a small offset that accumulates.

> > 

> > How can this happen? Can anyone explain how time is kept in coLinux? I

> know

> > that vmWare and HyperV have special tools for keeping the VM clock in

> sync.

> > Is there anything similar in coLinux?

> > What are the recommendations for keeping time in coLinux?

> > 

> > 

> > In what direction goes the clock wrong? You lost 9 hours, or is it 9

> hours

> > in the future?

> > 

> > coLinux uses Windows timer with 10Hz (100ms) as time base. In the time

> > where Linux is not running, we count the "losed" ticks. Next time

> Linux is

> > running again, the internal Linux timer "jiffies" will adjust from the

> count

> > of "losed" timer ticks. For calculation the clock difference between

> last

> > Linux running and next Linux entry will calculate as difference into

> > "jiffies". The time base function on Windows side is

> > "KeQueryPerformanceCounter".

> > 

> > I don't know, why some machines have such big difference. One option

> would

> > be, if the Windows timer frequency is not stable, for example the

> clock

> > frequency will change from one to other call. Then we would count a

> wrong

> > timer difference.

> > The "clock frequency" is not the CPU frequency. It is the parameter we

> get

> > from KeQueryPerformanceCounter, and this should be the same value as

> long

> > the Windows machine is running. See

> > http://www.osronline.com/ddkx/kmarch/k105_3waa.htm

> > 

> > An other idea would be an overflow in the clock calculation, on

> machines

> > with very high "clock frequency".

> > 

> > Can you reproduce it? Maybe we can add some debug messages to check

> the

> > calculation, if the time difference from one to next Linux entry is

> more as

> > some seconds? Normal it is less than 100 ms, unless Windows goes into

> > suspend (to RAM or to disk) and will wakeup later.

> > 

> > --

> > Henry N.

> > 

> > 

> > 

> > 

> ------------------------------------------------------------------------------

> > This SF.net Dev2Dev email is sponsored by:

> > 

> > Show off your parallel programming skills.

> > Enter the Intel(R) Threading Challenge 2010.

> > http://p.sf.net/sfu/intel-thread-sfd

> > _______________________________________________

> > coLinux-users mailing list

> > coL...@li...

> > https://lists.sourceforge.net/lists/listinfo/colinux-users

> > 

> > 

> > 

> > 

> > --

> > Shai Vaingast

> > Author of Beginning Python Visualization

> > http://www.apress.com/book/view/1430218436

> > 

> > 

> > 

> > --

> > Henry N.

> > 

> > 

> > 

> > 

> ------------------------------------------------------------------------------

> > This SF.net Dev2Dev email is sponsored by:

> > 

> > Show off your parallel programming skills.

> > Enter the Intel(R) Threading Challenge 2010.

> > http://p.sf.net/sfu/intel-thread-sfd

> > _______________________________________________

> > coLinux-users mailing list

> > coL...@li...

> > https://lists.sourceforge.net/lists/listinfo/colinux-users

> > 

> > 

> 

<Attachment>   ATT00001

<Attachment>   ATT00002

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
coLinux-users mailing list
coL...@li...
https://lists.sourceforge.net/lists/listinfo/colinux-users 		 	   		  
I have seen some code to support the suggestion that it is down to the QueryPerformanceCounter and CPU scaling. I can't remember if it was in though. SFML, Ogre or Irrlicht are the most likely 
--
Sent from my Nokia N900

----- Original message -----
> Hi Henry and Ron,
> Just to verify, I have duplicated this problem on my PC as well. This
> appears to be related to the selected Power Options settings (Control
> Panel,
> Power Options). I believe this can also happen if you have a variable
> frequency CPU as the time calculation is performed using
> QueryPerformanceCounter which counts CPU cycles and not time.
> Ron, can you verify this by disabling power options in your host?
> Thanks,
> - Shai
> 
> On Fri, Sep 3, 2010 at 1:42 AM, Henry Nestler <hen...@ar...> wrote:
> 
> > Hello Ron,
> > 
> > we don't use RDTSC directly. We use windows API, and that should work
> > without problems. KeQueryPerformanceCounter is the only function with
> > smallest time interval. Of curse I also have seen updates for broken
> > KeQueryPerformanceCounter: http://support.microsoft.com/kb/896256
> > 
> > The problem is not to follow the time. If the timediff is more as one
> > second, for example if you suspend Windows, then we set the time
> absolutely.
> > The problem is, from where we can get the exact time stamp, if
> > KeQueryPerformanceCounter is wrong?
> > 
> > Here we have the two calculations. One on Windows side, here we
> calculate
> > the difference of "jiffies" in callback_return_jiffies:
> > 
> > 
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/kernel/monitor.c?view=markup#l366
> > 
> > co_os_get_timestamp is here:
> > 
> > 
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31
> > 
> > On Linux side we increment teh jiffies and time here in function
> > co_handle_jiffies:
> > 
> > 
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/base-2.6.33.diff?view=markup#l2563
> > 
> > I will create more debug for cases of "time warps".
> > 
> > --
> > Henry
> > 
> > 
> > 
> > On 02.09.2010 13:06, Ron Avriel wrote:
> > 
> > Hi Henry and Shai,
> > 
> > Thanks for answers.
> > Here are some answers and more information:
> > 
> > The time always advanced to the future, so far.
> > In one coLinux it jumped forward 30944 seconds, and in another it
> jumped
> > more than 24 hours (I don't have the exact number).
> > The processor is an Intel Pentium 1.4 GHz.
> > QueryPerformanceFrequency on the server returns 3579545.
> > 
> > The problem already occurred several times on different servers, but
> it can
> > take days or weeks until it happens.
> > 
> > I think RDTSC is not a good idea for time measurement, because its
> speed
> > can change. Are you sure it's used in coLinux?
> > 
> > It seems to me that the problem is related to some wrong overflow
> > calculation. I'd check in that direction.
> > I also think that special handling is required if time difference
> between
> > coLinux wakeups is too large. Perhaps in that case you should get the
> real
> > time from Windows, like you do on startup?
> > 
> > Thanks,
> > Ron
> > 
> > Date: Thu, 2 Sep 2010 10:39:10 +0300
> > Subject: Re: [coLinux-users] Very large time offset in coLinux
> > From: sva...@gm...
> > To: hen...@ar...
> > CC: ra...@ho...; col...@li...
> > 
> > Hi Ron,
> > 
> > Do you use an AMD processor? If so, can you please be more specific,
> which
> > one? I *think* that this could be related to an issue I've seen with
> RDTSC
> > which reports the clock frequency, usually in accordance with
> > QueryPerformanceFrequency (could be a different API, not sure) but has
> some
> > problems with AMD processors. There should be a workaround, I'll have
> to dig
> > more into this.
> > Another option is that the RDTSC is not updated properly when the
> system is
> > in sleep (power maangement). Can you try again without power
> management
> > enabled and see if the issue is resolved?
> > 
> > Thanks,
> > 
> > - Shai
> > 
> > On Thu, Sep 2, 2010 at 2:42 AM, Henry Nestler <hen...@ar...>
> wrote:
> > 
> > On 01.09.2010 13:37, Ron Avriel wrote:
> > 
> > Hi,
> > 
> > I have several coLinux running in different Windows hosts.
> Occasionally,
> > the time in coLinux advances by several hours and up to a day!
> > The time on the Windows hosts always remains correct.
> > This happened on multiple coLinux servers, some of them ran NTP, but
> it
> > seems that NTP will not adjust clock if the offset is too large. It
> also
> > happened on a server that did not run NTP.
> > 
> > It should be noted that that the the large offset of 9 hours or more
> > happened at once. It's not a small offset that accumulates.
> > 
> > How can this happen? Can anyone explain how time is kept in coLinux? I
> know
> > that vmWare and HyperV have special tools for keeping the VM clock in
> sync.
> > Is there anything similar in coLinux?
> > What are the recommendations for keeping time in coLinux?
> > 
> > 
> > In what direction goes the clock wrong? You lost 9 hours, or is it 9
> hours
> > in the future?
> > 
> > coLinux uses Windows timer with 10Hz (100ms) as time base. In the time
> > where Linux is not running, we count the "losed" ticks. Next time
> Linux is
> > running again, the internal Linux timer "jiffies" will adjust from the
> count
> > of "losed" timer ticks. For calculation the clock difference between
> last
> > Linux running and next Linux entry will calculate as difference into
> > "jiffies". The time base function on Windows side is
> > "KeQueryPerformanceCounter".
> > 
> > I don't know, why some machines have such big difference. One option
> would
> > be, if the Windows timer frequency is not stable, for example the
> clock
> > frequency will change from one to other call. Then we would count a
> wrong
> > timer difference.
> > The "clock frequency" is not the CPU frequency. It is the parameter we
> get
> > from KeQueryPerformanceCounter, and this should be the same value as
> long
> > the Windows machine is running. See
> > http://www.osronline.com/ddkx/kmarch/k105_3waa.htm
> > 
> > An other idea would be an overflow in the clock calculation, on
> machines
> > with very high "clock frequency".
> > 
> > Can you reproduce it? Maybe we can add some debug messages to check
> the
> > calculation, if the time difference from one to next Linux entry is
> more as
> > some seconds? Normal it is less than 100 ms, unless Windows goes into
> > suspend (to RAM or to disk) and will wakeup later.
> > 
> > --
> > Henry N.
> > 
> > 
> > 
> > 
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> > 
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > coLinux-users mailing list
> > coL...@li...
> > https://lists.sourceforge.net/lists/listinfo/colinux-users
> > 
> > 
> > 
> > 
> > --
> > Shai Vaingast
> > Author of Beginning Python Visualization
> > http://www.apress.com/book/view/1430218436
> > 
> > 
> > 
> > --
> > Henry N.
> > 
> > 
> > 
> > 
> ------------------------------------------------------------------------------
> > This SF.net Dev2Dev email is sponsored by:
> > 
> > Show off your parallel programming skills.
> > Enter the Intel(R) Threading Challenge 2010.
> > http://p.sf.net/sfu/intel-thread-sfd
> > _______________________________________________
> > coLinux-users mailing list
> > coL...@li...
> > https://lists.sourceforge.net/lists/listinfo/colinux-users
> > 
> > 
> 

<Attachment>   ATT00001
<Attachment>   ATT00002

Hi Henry and Ron,
Just to verify, I have duplicated this problem on my PC as well.  This
appears to be related to the selected Power Options settings (Control Panel,
Power Options).  I believe this can also happen if you have a variable
frequency CPU as the time calculation is performed using
QueryPerformanceCounter which counts CPU cycles and not time.
Ron, can you verify this by disabling power options in your host?
Thanks,
- Shai

On Fri, Sep 3, 2010 at 1:42 AM, Henry Nestler <hen...@ar...> wrote:

> Hello Ron,
>
> we don't use RDTSC directly. We use windows API, and that should work
> without problems. KeQueryPerformanceCounter is the only function with
> smallest time interval. Of curse I also have seen updates for broken
> KeQueryPerformanceCounter: http://support.microsoft.com/kb/896256
>
> The problem is not to follow the time. If the timediff is more as one
> second, for example if you suspend Windows, then we set the time absolutely.
> The problem is, from where we can get the exact time stamp, if
> KeQueryPerformanceCounter is wrong?
>
> Here we have the two calculations. One on Windows side, here we calculate
> the difference of "jiffies" in callback_return_jiffies:
>
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/kernel/monitor.c?view=markup#l366
>
> co_os_get_timestamp is here:
>
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31
>
> On Linux side we increment teh jiffies and time here in function
> co_handle_jiffies:
>
> http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/base-2.6.33.diff?view=markup#l2563
>
> I will create more debug for cases of "time warps".
>
> --
> Henry
>
>
>
> On 02.09.2010 13:06, Ron Avriel wrote:
>
> Hi Henry and Shai,
>
> Thanks for answers.
> Here are some answers and more information:
>
> The time always advanced to the future, so far.
> In one coLinux it jumped forward 30944 seconds, and in another it jumped
> more than 24 hours (I don't have the exact number).
> The processor is an Intel Pentium 1.4 GHz.
> QueryPerformanceFrequency on the server returns 3579545.
>
> The problem already occurred several times on different servers, but it can
> take days or weeks until it happens.
>
> I think RDTSC is not a good idea for time measurement, because its speed
> can change. Are you sure it's used in coLinux?
>
> It seems to me that the problem is related to some wrong overflow
> calculation. I'd check in that direction.
> I also think that special handling is required if time difference between
> coLinux wakeups is too large. Perhaps in that case you should get the real
> time from Windows, like you do on startup?
>
> Thanks,
> Ron
>
> Date: Thu, 2 Sep 2010 10:39:10 +0300
> Subject: Re: [coLinux-users] Very large time offset in coLinux
> From: sva...@gm...
> To: hen...@ar...
> CC: ra...@ho...; col...@li...
>
>  Hi Ron,
>
> Do you use an AMD processor?  If so, can you please be more specific, which
> one?  I *think* that this could be related to an issue I've seen with RDTSC
> which reports the clock frequency, usually in accordance with
> QueryPerformanceFrequency (could be a different API, not sure) but has some
> problems with AMD processors. There should be a workaround, I'll have to dig
> more into this.
> Another option is that the RDTSC is not updated properly when the system is
> in sleep (power maangement).  Can you try again without power management
> enabled and see if the issue is resolved?
>
> Thanks,
>
> - Shai
>
> On Thu, Sep 2, 2010 at 2:42 AM, Henry Nestler <hen...@ar...> wrote:
>
>  On 01.09.2010 13:37, Ron Avriel wrote:
>
> Hi,
>
> I have several coLinux running in different Windows hosts. Occasionally,
> the time in coLinux advances by several hours and up to a day!
> The time on the Windows hosts always remains correct.
> This happened on multiple coLinux servers, some of them ran NTP, but it
> seems that NTP will not adjust clock if the offset is too large. It also
> happened on a server that did not run NTP.
>
> It should be noted that that the the large offset of 9 hours or more
> happened at once. It's not a small offset that accumulates.
>
> How can this happen? Can anyone explain how time is kept in coLinux? I know
> that vmWare and HyperV have special tools for keeping the VM clock in sync.
> Is there anything similar in coLinux?
> What are the recommendations for keeping time in coLinux?
>
>
> In what direction goes the clock wrong? You lost 9 hours, or is it 9 hours
> in the future?
>
> coLinux uses Windows timer with 10Hz (100ms) as time base. In the time
> where Linux is not running, we count the "losed" ticks. Next time Linux is
> running again, the internal Linux timer "jiffies" will adjust from the count
> of "losed" timer ticks. For calculation the clock difference between last
> Linux running and next Linux entry will calculate as difference into
> "jiffies". The time base function on Windows side is
> "KeQueryPerformanceCounter".
>
> I don't know, why some machines have such big difference. One option would
> be, if the Windows timer frequency is not stable, for example the clock
> frequency will change from one to other call. Then we would count a wrong
> timer difference.
> The "clock frequency" is not the CPU frequency. It is the parameter we get
> from KeQueryPerformanceCounter, and this should be the same value as long
> the Windows machine is running. See
> http://www.osronline.com/ddkx/kmarch/k105_3waa.htm
>
> An other idea would be an overflow in the clock calculation, on machines
> with very high "clock frequency".
>
> Can you reproduce it? Maybe we can add some debug messages to check the
> calculation, if the time difference from one to next Linux entry is more as
> some seconds? Normal it is less than 100 ms, unless Windows goes into
> suspend (to RAM or to disk) and will wakeup later.
>
> --
> Henry N.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> coLinux-users mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>
>
>
>
> --
> Shai Vaingast
> Author of Beginning Python Visualization
> http://www.apress.com/book/view/1430218436
>
>
>
> --
> Henry N.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> coLinux-users mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>
>

Hi Henry,

Can you please explain why you multiply by 100 in 

timestamp_diff += 100 * (((long long)timestamp.quad) - ((long long)cmon->timestamp.quad));  /* HZ value */

http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31

If this function is called every 100ms, as you previously wrote, then you get 10 jiffies per call. Shouldn't it be 1 jiffy per 100ms? Shouldn't you multiply by 10 instead?

I guess your calculation is right, but I can't figure it out.

Thanks,
Ron

Date: Fri, 3 Sep 2010 00:42:47 +0200
From: hen...@ar...
To: ra...@ho...
CC: col...@li...
Subject: Re: [coLinux-users] Very large time offset in coLinux

    Message body

    Hello Ron,

    we don't use RDTSC directly. We use windows API, and that should
    work without problems. KeQueryPerformanceCounter is the only
    function with smallest time interval. Of curse I also have seen
    updates for broken KeQueryPerformanceCounter:
    http://support.microsoft.com/kb/896256

    The problem is not to follow the time. If the timediff is more as
    one second, for example if you suspend Windows, then we set the time
    absolutely. The problem is, from where we can get the exact time
    stamp, if KeQueryPerformanceCounter is wrong?

    Here we have the two calculations. One on Windows side, here we
    calculate the difference of "jiffies" in callback_return_jiffies:

    http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/kernel/monitor.c?view=markup#l366

    co_os_get_timestamp is here:

http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31

    On Linux side we increment teh jiffies and time here in function co_handle_jiffies:

http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/base-2.6.33.diff?view=markup#l2563

    I will create more debug for cases of "time warps".

    --

    Henry

  Hello Ron,

we don't use RDTSC directly. We use windows API, and that should work 
without problems. KeQueryPerformanceCounter is the only function with 
smallest time interval. Of curse I also have seen updates for broken 
KeQueryPerformanceCounter: http://support.microsoft.com/kb/896256

The problem is not to follow the time. If the timediff is more as one 
second, for example if you suspend Windows, then we set the time 
absolutely. The problem is, from where we can get the exact time stamp, 
if KeQueryPerformanceCounter is wrong?

Here we have the two calculations. One on Windows side, here we 
calculate the difference of "jiffies" in callback_return_jiffies:
http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/kernel/monitor.c?view=markup#l366

co_os_get_timestamp is here:
http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/src/colinux/os/winnt/kernel/lowlevel/time.c?view=markup#l31

On Linux side we increment teh jiffies and time here in function 
co_handle_jiffies:
http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/base-2.6.33.diff?view=markup#l2563

I will create more debug for cases of "time warps".

--
Henry

On 02.09.2010 13:06, Ron Avriel wrote:
> Hi Henry and Shai,
>
> Thanks for answers.
> Here are some answers and more information:
>
> The time always advanced to the future, so far.
> In one coLinux it jumped forward 30944 seconds, and in another it 
> jumped more than 24 hours (I don't have the exact number).
> The processor is an Intel Pentium 1.4 GHz.
> QueryPerformanceFrequency on the server returns 3579545.
>
> The problem already occurred several times on different servers, but 
> it can take days or weeks until it happens.
>
> I think RDTSC is not a good idea for time measurement, because its 
> speed can change. Are you sure it's used in coLinux?
>
> It seems to me that the problem is related to some wrong overflow 
> calculation. I'd check in that direction.
> I also think that special handling is required if time difference 
> between coLinux wakeups is too large. Perhaps in that case you should 
> get the real time from Windows, like you do on startup?
>
> Thanks,
> Ron
>
> Date: Thu, 2 Sep 2010 10:39:10 +0300
> Subject: Re: [coLinux-users] Very large time offset in coLinux
> From: sva...@gm...
> To: hen...@ar...
> CC: ra...@ho...; col...@li...
>
> Hi Ron,
> Do you use an AMD processor?  If so, can you please be more specific, 
> which one?  I *think* that this could be related to an issue I've seen 
> with RDTSC which reports the clock frequency, usually in accordance 
> with QueryPerformanceFrequency (could be a different API, not sure) 
> but has some problems with AMD processors. There should be a 
> workaround, I'll have to dig more into this.
> Another option is that the RDTSC is not updated properly when the 
> system is in sleep (power maangement).  Can you try again without 
> power management enabled and see if the issue is resolved?
> Thanks,
> - Shai
>
> On Thu, Sep 2, 2010 at 2:42 AM, Henry Nestler <hen...@ar...> wrote:
>
>     On 01.09.2010 13:37, Ron Avriel wrote:
>
>         Hi,
>
>         I have several coLinux running in different Windows hosts.
>         Occasionally, the time in coLinux advances by several hours
>         and up to a day!
>         The time on the Windows hosts always remains correct.
>         This happened on multiple coLinux servers, some of them ran
>         NTP, but it seems that NTP will not adjust clock if the offset
>         is too large. It also happened on a server that did not run NTP.
>
>         It should be noted that that the the large offset of 9 hours
>         or more happened at once. It's not a small offset that
>         accumulates.
>
>         How can this happen? Can anyone explain how time is kept in
>         coLinux? I know that vmWare and HyperV have special tools for
>         keeping the VM clock in sync. Is there anything similar in
>         coLinux?
>         What are the recommendations for keeping time in coLinux?
>
>
>     In what direction goes the clock wrong? You lost 9 hours, or is it
>     9 hours in the future?
>
>     coLinux uses Windows timer with 10Hz (100ms) as time base. In the
>     time where Linux is not running, we count the "losed" ticks. Next
>     time Linux is running again, the internal Linux timer "jiffies"
>     will adjust from the count of "losed" timer ticks. For calculation
>     the clock difference between last Linux running and next Linux
>     entry will calculate as difference into "jiffies". The time base
>     function on Windows side is "KeQueryPerformanceCounter".
>
>     I don't know, why some machines have such big difference. One
>     option would be, if the Windows timer frequency is not stable, for
>     example the clock frequency will change from one to other call.
>     Then we would count a wrong timer difference.
>     The "clock frequency" is not the CPU frequency. It is the
>     parameter we get from KeQueryPerformanceCounter, and this should
>     be the same value as long the Windows machine is running. See
>     http://www.osronline.com/ddkx/kmarch/k105_3waa.htm
>
>     An other idea would be an overflow in the clock calculation, on
>     machines with very high "clock frequency".
>
>     Can you reproduce it? Maybe we can add some debug messages to
>     check the calculation, if the time difference from one to next
>     Linux entry is more as some seconds? Normal it is less than 100
>     ms, unless Windows goes into suspend (to RAM or to disk) and will
>     wakeup later.
>
>     -- 
>     Henry N.
>
>
>     ------------------------------------------------------------------------------
>     This SF.net Dev2Dev email is sponsored by:
>
>     Show off your parallel programming skills.
>     Enter the Intel(R) Threading Challenge 2010.
>     http://p.sf.net/sfu/intel-thread-sfd
>     _______________________________________________
>     coLinux-users mailing list
>     coL...@li...
>     https://lists.sourceforge.net/lists/listinfo/colinux-users
>
>
>
>
> -- 
> Shai Vaingast
> Author of Beginning Python Visualization
> http://www.apress.com/book/view/1430218436

-- 
Henry N.

Hi Henry and Shai,

Thanks for answers.
Here are some answers and more information:

The time always advanced to the future, so far.
In one coLinux it jumped forward 30944 seconds, and in another it jumped more than 24 hours (I don't have the exact number).
The processor is an Intel Pentium 1.4 GHz. 
QueryPerformanceFrequency on the server returns 3579545.

The problem already occurred several times on different servers, but it can take days or weeks until it happens.

I think RDTSC is not a good idea for time measurement, because its speed can change. Are you sure it's used in coLinux?

It seems to me that the problem is related to some wrong overflow calculation. I'd check in that direction.
I also think that special handling is required if time difference between coLinux wakeups is too large. Perhaps in that case you should get the real time from Windows, like you do on startup?

Thanks,
Ron

Date: Thu, 2 Sep 2010 10:39:10 +0300
Subject: Re: [coLinux-users] Very large time offset in coLinux
From: sva...@gm...
To: hen...@ar...
CC: ra...@ho...; col...@li...

Hi Ron,

Do you use an AMD processor?  If so, can you please be more specific, which one?  I *think* that this could be related to an issue I've seen with RDTSC which reports the clock frequency, usually in accordance with QueryPerformanceFrequency (could be a different API, not sure) but has some problems with AMD processors. There should be a workaround, I'll have to dig more into this.

Another option is that the RDTSC is not updated properly when the system is in sleep (power maangement).  Can you try again without power management enabled and see if the issue is resolved?

Thanks,

- Shai

On Thu, Sep 2, 2010 at 2:42 AM, Henry Nestler <hen...@ar...> wrote:

On 01.09.2010 13:37, Ron Avriel wrote: 
Hi,

I have several coLinux running in different Windows hosts. Occasionally, the time in coLinux advances by several hours and up to a day!
The time on the Windows hosts always remains correct.

This happened on multiple coLinux servers, some of them ran NTP, but it seems that NTP will not adjust clock if the offset is too large. It also happened on a server that did not run NTP.

It should be noted that that the the large offset of 9 hours or more happened at once. It's not a small offset that accumulates.

How can this happen? Can anyone explain how time is kept in coLinux? I know that vmWare and HyperV have special tools for keeping the VM clock in sync. Is there anything similar in coLinux?
What are the recommendations for keeping time in coLinux?

In what direction goes the clock wrong? You lost 9 hours, or is it 9 hours in the future?

coLinux uses Windows timer with 10Hz (100ms) as time base. In the time where Linux is not running, we count the "losed" ticks. Next time Linux is running again, the internal Linux timer "jiffies" will adjust from the count of "losed" timer ticks. For calculation the clock difference between last Linux running and next Linux entry will calculate as difference into "jiffies". The time base function on Windows side is "KeQueryPerformanceCounter".

I don't know, why some machines have such big difference. One option would be, if the Windows timer frequency is not stable, for example the clock frequency will change from one to other call. Then we would count a wrong timer difference.

The "clock frequency" is not the CPU frequency. It is the parameter we get from KeQueryPerformanceCounter, and this should be the same value as long the Windows machine is running. See http://www.osronline.com/ddkx/kmarch/k105_3waa.htm

An other idea would be an overflow in the clock calculation, on machines with very high "clock frequency".

Can you reproduce it? Maybe we can add some debug messages to check the calculation, if the time difference from one to next Linux entry is more as some seconds? Normal it is less than 100 ms, unless Windows goes into suspend (to RAM or to disk) and will wakeup later.

-- 
Henry N.

------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:

Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.

http://p.sf.net/sfu/intel-thread-sfd
_______________________________________________
coLinux-users mailing list
coL...@li...

https://lists.sourceforge.net/lists/listinfo/colinux-users

-- 
Shai Vaingast

Author of Beginning Python Visualization
http://www.apress.com/book/view/1430218436

Hi Ron,

Do you use an AMD processor?  If so, can you please be more specific, which
one?  I *think* that this could be related to an issue I've seen with RDTSC
which reports the clock frequency, usually in accordance with
QueryPerformanceFrequency (could be a different API, not sure) but has some
problems with AMD processors. There should be a workaround, I'll have to dig
more into this.
Another option is that the RDTSC is not updated properly when the system is
in sleep (power maangement).  Can you try again without power management
enabled and see if the issue is resolved?

Thanks,

- Shai

On Thu, Sep 2, 2010 at 2:42 AM, Henry Nestler <hen...@ar...> wrote:

>   On 01.09.2010 13:37, Ron Avriel wrote:
>
> Hi,
>
> I have several coLinux running in different Windows hosts. Occasionally,
> the time in coLinux advances by several hours and up to a day!
> The time on the Windows hosts always remains correct.
> This happened on multiple coLinux servers, some of them ran NTP, but it
> seems that NTP will not adjust clock if the offset is too large. It also
> happened on a server that did not run NTP.
>
> It should be noted that that the the large offset of 9 hours or more
> happened at once. It's not a small offset that accumulates.
>
> How can this happen? Can anyone explain how time is kept in coLinux? I know
> that vmWare and HyperV have special tools for keeping the VM clock in sync.
> Is there anything similar in coLinux?
> What are the recommendations for keeping time in coLinux?
>
>
> In what direction goes the clock wrong? You lost 9 hours, or is it 9 hours
> in the future?
>
> coLinux uses Windows timer with 10Hz (100ms) as time base. In the time
> where Linux is not running, we count the "losed" ticks. Next time Linux is
> running again, the internal Linux timer "jiffies" will adjust from the count
> of "losed" timer ticks. For calculation the clock difference between last
> Linux running and next Linux entry will calculate as difference into
> "jiffies". The time base function on Windows side is
> "KeQueryPerformanceCounter".
>
> I don't know, why some machines have such big difference. One option would
> be, if the Windows timer frequency is not stable, for example the clock
> frequency will change from one to other call. Then we would count a wrong
> timer difference.
> The "clock frequency" is not the CPU frequency. It is the parameter we get
> from KeQueryPerformanceCounter, and this should be the same value as long
> the Windows machine is running. See
> http://www.osronline.com/ddkx/kmarch/k105_3waa.htm
>
> An other idea would be an overflow in the clock calculation, on machines
> with very high "clock frequency".
>
> Can you reproduce it? Maybe we can add some debug messages to check the
> calculation, if the time difference from one to next Linux entry is more as
> some seconds? Normal it is less than 100 ms, unless Windows goes into
> suspend (to RAM or to disk) and will wakeup later.
>
> --
> Henry N.
>
>
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
> http://p.sf.net/sfu/intel-thread-sfd
> _______________________________________________
> coLinux-users mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-users
>
>

-- 
Shai Vaingast
Author of Beginning Python Visualization
http://www.apress.com/book/view/1430218436

  On 01.09.2010 13:37, Ron Avriel wrote:
> Hi,
>
> I have several coLinux running in different Windows hosts. 
> Occasionally, the time in coLinux advances by several hours and up to 
> a day!
> The time on the Windows hosts always remains correct.
> This happened on multiple coLinux servers, some of them ran NTP, but 
> it seems that NTP will not adjust clock if the offset is too large. It 
> also happened on a server that did not run NTP.
>
> It should be noted that that the the large offset of 9 hours or more 
> happened at once. It's not a small offset that accumulates.
>
> How can this happen? Can anyone explain how time is kept in coLinux? I 
> know that vmWare and HyperV have special tools for keeping the VM 
> clock in sync. Is there anything similar in coLinux?
> What are the recommendations for keeping time in coLinux?

In what direction goes the clock wrong? You lost 9 hours, or is it 9 
hours in the future?

coLinux uses Windows timer with 10Hz (100ms) as time base. In the time 
where Linux is not running, we count the "losed" ticks. Next time Linux 
is running again, the internal Linux timer "jiffies" will adjust from 
the count of "losed" timer ticks. For calculation the clock difference 
between last Linux running and next Linux entry will calculate as 
difference into "jiffies". The time base function on Windows side is 
"KeQueryPerformanceCounter".

I don't know, why some machines have such big difference. One option 
would be, if the Windows timer frequency is not stable, for example the 
clock frequency will change from one to other call. Then we would count 
a wrong timer difference.
The "clock frequency" is not the CPU frequency. It is the parameter we 
get from KeQueryPerformanceCounter, and this should be the same value as 
long the Windows machine is running. See 
http://www.osronline.com/ddkx/kmarch/k105_3waa.htm

An other idea would be an overflow in the clock calculation, on machines 
with very high "clock frequency".

Can you reproduce it? Maybe we can add some debug messages to check the 
calculation, if the time difference from one to next Linux entry is more 
as some seconds? Normal it is less than 100 ms, unless Windows goes into 
suspend (to RAM or to disk) and will wakeup later.

-- 
Henry N.

Hi,

I have several coLinux running in different Windows hosts. Occasionally, the time in coLinux advances by several hours and up to a day!
The time on the Windows hosts always remains correct.
This happened on multiple coLinux servers, some of them ran NTP, but it seems that NTP will not adjust clock if the offset is too large. It also happened on a server that did not run NTP.

It should be noted that that the the large offset of 9 hours or more happened at once. It's not a small offset that accumulates.

How can this happen? Can anyone explain how time is kept in coLinux? I know that vmWare and HyperV have special tools for keeping the VM clock in sync. Is there anything similar in coLinux?
What are the recommendations for keeping time in coLinux?

Thanks for a great product,
Ron

hi,all
    i am trying to run coLinux on my server(cpu: intel xeon 5405 * 2 VT-x
enabled, OS: windows server 2003 32bit), when i finish installing and
configing colinux, i run the coLinux. but the host crashed (BSOD),so has
some body knows that coLinux can run on xeon 5405 and windows server 2003
32bit?

  On 10.08.2010 17:45, Mike Mestnik wrote:
> On 8/9/2010 5:00 PM, Henry Nestler wrote:
>> I hope 00:18:8B:26:42:84 is an number you have self created, and not
>> exist on any card. Better you should start with 02, not with 00 there.
>> 00 can be real hardware. 02 can never be a real hardware, it's defined
>> as "controlled by user". So, 02:18:8B:26:42:84 would be be better for
>> you.
>>
> My understanding is that the first 3 octets indicate the vendor, are you
> indicating that 02:xx:yy indicates a vendor-less address?

Setting the bit 1 is in first byte a sing, that you manually control 
this MAC in a local network. Never of real hardware cards have set this bit.
See http://en.wikipedia.org/wiki/MAC_address#Address_details

-- 
Henry N.

On 8/9/2010 5:00 PM, Henry Nestler wrote:
>  On 09.08.2010 19:21, Mike Mestnik wrote:
>> On 8/9/2010 12:40 PM, Mike Mestnik wrote:
>>> On 8/6/2010 3:08 PM, Henry Nestler wrote:
>>>>   Hello Mike,
>>>>
>>>> a big difference between pcap-bride and ndis-bride exist inside the
>>>> code for auto probing name.
>>>>
>>>> pcap-bridge: Checks that the interface has an IP address.
>>>> ndis-bride: Does *not* check IP address. ndis simple use the first
>>>> network adapter it will find.
>>>>
>>>> So, auto probing the name for ndis would fail in mostly all cases.
>>>> On an other desktop here for me, ndis found a network card, that no
>>>> longer exist, becaus I have replaced with a new card. :-(
>>>>
>>> I gave tap/ndis-bridge another try renaming and specifying both names,
>>> (tap0/eth0) and this failed.
>>>
>>> It may vary well work on an interface that does not have an IP
>>> address, it's an interface that does not have link that would be a
>>> problem.  Given a system with two interfaces makes auto probing a
>>> possibility, perhaps if there are more interfaces then there are
>>> interface definitions it should fail.  Also note all the interfaces
>>> could be setup for DHCP... so getting the interfaces in the correct
>>> order may not be an issue and it should not be an issue because
>>> interface probing order is already a known issue.  Perhaps instead of
>>> a randomly generated address one should be based of the address it's
>>> bound with, this way udev's persistent code would work as intended and
>>> there'd be no-more need for the registry saving that's also causing
>>> problems.
>>>
>>>
>>> Given the current status I'm migrating to slirp, though I'd be
>>> interested in testing solutions to the un-identified problem I'm 
>>> having.
>>>
>> This is what I have on my local instance that I use day-to-day:
>> eth0=ndis-bridge,,00:18:8B:26:42:84
>> eth1=tuntap,,00:18:8B:26:44:80
>>
>> Every thing is fine with this, reboot and it's still all good.  This
>> makes me think it's a mistake to try and set the name and instead the
>> real solution is to set a random address.
>
> If the MAC is your problem, you would see a "eth0: no such device" in 
> the running Linux, and the renamed part eth2 or higher in /proc/net/dev.
>
I've disabled renaming in udev, this is easily correctable and you 
should have a howto instead of insisting the interface names will be 
changed automatically.

Perhaps you should work with the udev ppl to implement a blacklisted 
range...  I.E. if the mac address starts with XYZ then don't rename it 
ever, or rather opt it out of the persistent database...  Perhaps only 
existing as a remark/placeholder.  That's another note colinux(or linux 
in general) should have a system for issuing mac addresses to software 
cards and taps.

> Without given name on ndis-bridge this can work. Maybe. It depends on 
> the sorting in your registry. But, it would not work every time on 
> everybody machines.
>
> If you create a setup, than you should give the user a selection from 
> the list of networkadpters and the user should enable, on which one 
> the bridge should connected to. The list you will find under 
> "SYSTEM\CurrentControlSet\Control\\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}", 
> the same list ndis-bridge used for name search.
>
I'll keep that in mind for future version, however automation is key.

> For the detecting interface which has an ip address (currently only 
> coded on "pcap-bridge"): The idea is, that pcap-bridge should 
> automatically find the interface you currently use to the world. This 
> interface in normal situation has an ip address at the time you starts 
> coLinux. This makes no difference of static IP or DHCP. And last: Auto 
> probing name for pcap-bridge or ndis-bridge is never optimal. It's an 
> help for simple environments with single network card only.
>
Another senerio would have all traffic routed through colinux and thus 
this device would intentionally not have an address.  It's not bad, but 
it's not good either.  That is this is neither a bug nor a feature.

> TAP-Win32 device you not need to rename, as long you only have one 
> coLinux TAP installed. TAP-Win32 for coLinux has a special ID and will 
> find in every cases.
>
> I hope 00:18:8B:26:42:84 is an number you have self created, and not 
> exist on any card. Better you should start with 02, not with 00 there. 
> 00 can be real hardware. 02 can never be a real hardware, it's defined 
> as "controlled by user". So, 02:18:8B:26:42:84 would be be better for 
> you.
>
My understanding is that the first 3 octets indicate the vendor, are you 
indicating that 02:xx:yy indicates a vendor-less address?

I'm unconcerned about collisions, I'm not on a huge network and I'd 
wonder who is.  It will *usually* be sufficient as long as it's not a 
copy of something else...  I'm sure every one has a "one day I had two 
nic cards and..." story to tell there children...  It'd probably start 
with back in my day we only had 48bits both ways...

> For ndis-bridge or pcap-bridge the MAC can be calculated from bounded 
> device, maybe. But, what should do with tuntap (Win-TAP32)? This type 
> has no reference. So, the globale rule is: If user does not set a MAC, 
> we use ones random created MAC. There exist no problem, if the user 
> will run only as Service or an other user will run only from command 
> line. The problem exist only for users, that would try to run command 
> line and the service with same root image. Typically users disable the 
> udev for inside the image and never have a problem again (see 
> http://colinux.wikia.com/wiki/Wubi#udev:_renamed_network_interface_eth0_to_eth2). 
> Other users sets a MAC and also have no problems.
>
The tap has an address as well, though who assigns it and where is it 
stored being another mattor.  I'd say it's likely not to change based on 
the current user, thus making it a good choice for the "where should I 
load this from?" question.  The TAP is another device on a virtual cross 
over cable and it shouldn't have the same address on both ends...  
Though being it's a PtP connection I can't see why that would be a 
problem, it would be broken for software to check and broken for a 
transmitter to care much for the receiver's address.

-- 
Mike Mestnik
Technical Team
___
Nagios Enterprises, INC.
Email:  mme...@na...
Web:    www.nagios.com

  On 09.08.2010 19:21, Mike Mestnik wrote:
> On 8/9/2010 12:40 PM, Mike Mestnik wrote:
>> On 8/6/2010 3:08 PM, Henry Nestler wrote:
>>>   Hello Mike,
>>>
>>> a big difference between pcap-bride and ndis-bride exist inside the
>>> code for auto probing name.
>>>
>>> pcap-bridge: Checks that the interface has an IP address.
>>> ndis-bride: Does *not* check IP address. ndis simple use the first
>>> network adapter it will find.
>>>
>>> So, auto probing the name for ndis would fail in mostly all cases.
>>> On an other desktop here for me, ndis found a network card, that no
>>> longer exist, becaus I have replaced with a new card. :-(
>>>
>> I gave tap/ndis-bridge another try renaming and specifying both names,
>> (tap0/eth0) and this failed.
>>
>> It may vary well work on an interface that does not have an IP
>> address, it's an interface that does not have link that would be a
>> problem.  Given a system with two interfaces makes auto probing a
>> possibility, perhaps if there are more interfaces then there are
>> interface definitions it should fail.  Also note all the interfaces
>> could be setup for DHCP... so getting the interfaces in the correct
>> order may not be an issue and it should not be an issue because
>> interface probing order is already a known issue.  Perhaps instead of
>> a randomly generated address one should be based of the address it's
>> bound with, this way udev's persistent code would work as intended and
>> there'd be no-more need for the registry saving that's also causing
>> problems.
>>
>>
>> Given the current status I'm migrating to slirp, though I'd be
>> interested in testing solutions to the un-identified problem I'm having.
>>
> This is what I have on my local instance that I use day-to-day:
> eth0=ndis-bridge,,00:18:8B:26:42:84
> eth1=tuntap,,00:18:8B:26:44:80
>
> Every thing is fine with this, reboot and it's still all good.  This
> makes me think it's a mistake to try and set the name and instead the
> real solution is to set a random address.

If the MAC is your problem, you would see a "eth0: no such device" in 
the running Linux, and the renamed part eth2 or higher in /proc/net/dev.

Without given name on ndis-bridge this can work. Maybe. It depends on 
the sorting in your registry. But, it would not work every time on 
everybody machines.

If you create a setup, than you should give the user a selection from 
the list of networkadpters and the user should enable, on which one the 
bridge should connected to. The list you will find under 
"SYSTEM\CurrentControlSet\Control\\Network\{4D36E972-E325-11CE-BFC1-08002BE10318}", 
the same list ndis-bridge used for name search.

For the detecting interface which has an ip address (currently only 
coded on "pcap-bridge"): The idea is, that pcap-bridge should 
automatically find the interface you currently use to the world. This 
interface in normal situation has an ip address at the time you starts 
coLinux. This makes no difference of static IP or DHCP. And last: Auto 
probing name for pcap-bridge or ndis-bridge is never optimal. It's an 
help for simple environments with single network card only.

TAP-Win32 device you not need to rename, as long you only have one 
coLinux TAP installed. TAP-Win32 for coLinux has a special ID and will 
find in every cases.

I hope 00:18:8B:26:42:84 is an number you have self created, and not 
exist on any card. Better you should start with 02, not with 00 there. 
00 can be real hardware. 02 can never be a real hardware, it's defined 
as "controlled by user". So, 02:18:8B:26:42:84 would be be better for you.

For ndis-bridge or pcap-bridge the MAC can be calculated from bounded 
device, maybe. But, what should do with tuntap (Win-TAP32)? This type 
has no reference. So, the globale rule is: If user does not set a MAC, 
we use ones random created MAC. There exist no problem, if the user will 
run only as Service or an other user will run only from command line. 
The problem exist only for users, that would try to run command line and 
the service with same root image. Typically users disable the udev for 
inside the image and never have a problem again (see 
http://colinux.wikia.com/wiki/Wubi#udev:_renamed_network_interface_eth0_to_eth2). 
Other users sets a MAC and also have no problems.

-- 
Henry N.

Hi, I'm enough. Please get me out of this mailing list, thanks a lot!

________________________________
From: Mike Mestnik <mme...@na...>
Cc: col...@li...
Sent: Mon, August 9, 2010 1:21:30 PM
Subject: Re: [coLinux-users] Networking: NSIS installer fails to configure tap 
correctly.

On 8/9/2010 12:40 PM, Mike Mestnik wrote:
> On 8/6/2010 3:08 PM, Henry Nestler wrote:
>>  Hello Mike,
>>
>> a big difference between pcap-bride and ndis-bride exist inside the 
>> code for auto probing name.
>>
>> pcap-bridge: Checks that the interface has an IP address.
>> ndis-bride: Does *not* check IP address. ndis simple use the first 
>> network adapter it will find.
>>
>> So, auto probing the name for ndis would fail in mostly all cases.
>> On an other desktop here for me, ndis found a network card, that no 
>> longer exist, becaus I have replaced with a new card. :-(
>>
> I gave tap/ndis-bridge another try renaming and specifying both names, 
> (tap0/eth0) and this failed.
>
> It may vary well work on an interface that does not have an IP 
> address, it's an interface that does not have link that would be a 
> problem.  Given a system with two interfaces makes auto probing a 
> possibility, perhaps if there are more interfaces then there are 
> interface definitions it should fail.  Also note all the interfaces 
> could be setup for DHCP... so getting the interfaces in the correct 
> order may not be an issue and it should not be an issue because 
> interface probing order is already a known issue.  Perhaps instead of 
> a randomly generated address one should be based of the address it's 
> bound with, this way udev's persistent code would work as intended and 
> there'd be no-more need for the registry saving that's also causing 
> problems.
>
>
> Given the current status I'm migrating to slirp, though I'd be 
> interested in testing solutions to the un-identified problem I'm having.
>
This is what I have on my local instance that I use day-to-day:
eth0=ndis-bridge,,00:18:8B:26:42:84
eth1=tuntap,,00:18:8B:26:44:80

Every thing is fine with this, reboot and it's still all good.  This 
makes me think it's a mistake to try and set the name and instead the 
real solution is to set a random address.

-- 
Mike Mestnik
Technical Team
___
Nagios Enterprises, INC.
Email:  mme...@na...
Web:    www.nagios.com

------------------------------------------------------------------------------
This SF.net email is sponsored by 

Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev 
_______________________________________________
coLinux-users mailing list
coL...@li...
https://lists.sourceforge.net/lists/listinfo/colinux-users

On 8/9/2010 12:40 PM, Mike Mestnik wrote:
> On 8/6/2010 3:08 PM, Henry Nestler wrote:
>>  Hello Mike,
>>
>> a big difference between pcap-bride and ndis-bride exist inside the 
>> code for auto probing name.
>>
>> pcap-bridge: Checks that the interface has an IP address.
>> ndis-bride: Does *not* check IP address. ndis simple use the first 
>> network adapter it will find.
>>
>> So, auto probing the name for ndis would fail in mostly all cases.
>> On an other desktop here for me, ndis found a network card, that no 
>> longer exist, becaus I have replaced with a new card. :-(
>>
> I gave tap/ndis-bridge another try renaming and specifying both names, 
> (tap0/eth0) and this failed.
>
> It may vary well work on an interface that does not have an IP 
> address, it's an interface that does not have link that would be a 
> problem.  Given a system with two interfaces makes auto probing a 
> possibility, perhaps if there are more interfaces then there are 
> interface definitions it should fail.  Also note all the interfaces 
> could be setup for DHCP... so getting the interfaces in the correct 
> order may not be an issue and it should not be an issue because 
> interface probing order is already a known issue.  Perhaps instead of 
> a randomly generated address one should be based of the address it's 
> bound with, this way udev's persistent code would work as intended and 
> there'd be no-more need for the registry saving that's also causing 
> problems.
>
>
> Given the current status I'm migrating to slirp, though I'd be 
> interested in testing solutions to the un-identified problem I'm having.
>
This is what I have on my local instance that I use day-to-day:
eth0=ndis-bridge,,00:18:8B:26:42:84
eth1=tuntap,,00:18:8B:26:44:80

Every thing is fine with this, reboot and it's still all good.  This 
makes me think it's a mistake to try and set the name and instead the 
real solution is to set a random address.

-- 
Mike Mestnik
Technical Team
___
Nagios Enterprises, INC.
Email:  mme...@na...
Web:    www.nagios.com

On 8/6/2010 3:08 PM, Henry Nestler wrote:
>  Hello Mike,
>
> a big difference between pcap-bride and ndis-bride exist inside the 
> code for auto probing name.
>
> pcap-bridge: Checks that the interface has an IP address.
> ndis-bride: Does *not* check IP address. ndis simple use the first 
> network adapter it will find.
>
> So, auto probing the name for ndis would fail in mostly all cases.
> On an other desktop here for me, ndis found a network card, that no 
> longer exist, becaus I have replaced with a new card. :-(
>
I gave tap/ndis-bridge another try renaming and specifying both names, 
(tap0/eth0) and this failed.

It may vary well work on an interface that does not have an IP address, 
it's an interface that does not have link that would be a problem.  
Given a system with two interfaces makes auto probing a possibility, 
perhaps if there are more interfaces then there are interface 
definitions it should fail.  Also note all the interfaces could be setup 
for DHCP... so getting the interfaces in the correct order may not be an 
issue and it should not be an issue because interface probing order is 
already a known issue.  Perhaps instead of a randomly generated address 
one should be based of the address it's bound with, this way udev's 
persistent code would work as intended and there'd be no-more need for 
the registry saving that's also causing problems.

Given the current status I'm migrating to slirp, though I'd be 
interested in testing solutions to the un-identified problem I'm having.

-- 
Mike Mestnik
Technical Team
___
Nagios Enterprises, INC.
Email:  mme...@na...
Web:    www.nagios.com

  Hello Mike,

a big difference between pcap-bride and ndis-bride exist inside the code 
for auto probing name.

pcap-bridge: Checks that the interface has an IP address.
ndis-bride: Does *not* check IP address. ndis simple use the first 
network adapter it will find.

So, auto probing the name for ndis would fail in mostly all cases.
On an other desktop here for me, ndis found a network card, that no 
longer exist, becaus I have replaced with a new card. :-(

-- 
Henry N.

  On 06.08.2010 02:22, Henry Nestler wrote:
> On 05.08.2010 22:31, Mike Mestnik wrote:
>> ...You should make debugging while running as a service as easy as
>> debugging while running as an application.
> It is included in Windows. ;-)
> Go to service-control manager and enable interaction with GUI, than you
> would see all the messages from colinux-daemon.

Sorry, not from the colinux-daemon.exe self. I don't know why.
You can see the networking daemons. Every in separate window.

-- 
Henry N.

  Hello Mike,

On 05.08.2010 22:31, Mike Mestnik wrote:
> On 8/5/2010 4:49 PM, Henry Nestler wrote:
>>   On 05.08.2010 21:00, Mike Mestnik wrote:
>>> I'll try some of these, thank you.
>>> ...What would I do if every thing works file when running as an
>>> application?
>> Add a MAC in coLinux config, than running from command line and as
>> service are identical fro the network issue.
> I got that logically these SHOULD be identical.  The truth seems as
> thought these are vary different.  Firstly you asked to run as an
> application and not as a service, so things sound different and look
> different.  Then there is the huge difference from being a service VS
> being an application, this surely will interject differences.  Finally
> the parameters passed are different, meaning logically these are
> different as different code paths are used.
>
> Thus testing as a service is a far cry from testing as an application,
> especially when you already are dealing with something that DOESN'T.
> DOESN'T i.m.h.o. usually outweighs any SHOULD CAN MAY or WILL.

Sorry, I don't know all what Windows changes for different users.
If you would configure the service to run as the desktop user (not as 
user "service"), than it is exactly identically to the command line.

Command line parser is exactly the same for both runs.
Of curse the location, what Windows will response are totaly different. 
We use "Current User" in registry to store the random MAC. "Current 
User" is different betwen service and command line. So you have an other 
set of ramdom generated MACs. So, for running as services and from 
command line and you wish to have the same MAC for both start options, 
you should use a self created MAC for all your network interfaces and 
write it into config.

Other differenes between command line and services are windows 
specifics. The main problem is that a "service" runs as other user as 
the desktop user. For example: Network Drive mappings are different, 
"C:\my files" is an other location, and so. For all these differences, 
you needs to use a static place in the config. For example for the 
drives: Don't use images on network drives or on replaceable (USB) disk. 
Don't use "C:\my files\...", use a path C:\coLinux, so it is all the 
same for all users on this machine.

>> If you leave blank the MAC, then coLinux use a random MAC, and this
>> number is different between the running from command line and running
>> as service.
>>
>> Next step would be to use "colinux-daemon --install-service ..." and
>> run it. You will have no differences.
>> Of curse the image files you have created should be writable for the
>> Windows account "Service".
>>
> Great, there is a method of testing...  Though it removes a variable I
> don't feel it will always satisfy the issue here.
>
> ...You should make debugging while running as a service as easy as
> debugging while running as an application.

It is included in Windows. ;-)
Go to service-control manager and enable interaction with GUI, than you 
would see all the messages from colinux-daemon.

>>>> 1. On startup the ndis-bride can attach to the TAP-Win32. That is a
>>>> loopback to coLinux self. To solve this, you should add the name of
>>>> real Ethernet card.
>>> Please add code to prevent this, only bind to a TAP-Win32 device if it's
>>> the only device or if it was specified by name.
>> This is not possible. The rule for empty name is: Using the first
>> adapter, that has a link connection.
> I don't see this at all.  If you can choose the first connection based
> on weather it has or has-not link you can choose not to choose a
> connection based on it's other qualities, like the name of it's driver.
>> The ndis does not know what network card is your choice. The
>> ndis-daemon is a separate daemon, that does not know some about the other
> If you don't know then do nothing, perhaps a bug in ndis.  I see this,
> but it should avoid potentially broken configs.
>> coLinux network daemons. You can have WLAN cards, cable cards, VPN
>> (also TAP-Win32).
>> If ndis should not use the first that it will find, then set a name
>> into the config.
>>
> Better this read "If you have to use a VPN connection you must set a
> name into the config.  However for most users it's safe to leave this
> blank."
> Currently it's vary unsafe to leave it blank and the docs don't point
> out that it's mandatory.  So if you can't fix this bug then make the
> name required and die if it's not set.
>> Other case you can sort the network order under Windows, so the
>> TAP-Win32 is not the first. This is of curse nothing for your installer.
> I don't get this?  If I could set the name of the TAP connection that
> would be great.  Adding this stuff to the installer is one fix, but ti's
> just the same as an installer telling the user to move files around and
> set registry keys...  Just not an optimal solution, better to fix this
> "once" in ndis or colinux instead of having every installer deal with it.

Setting the name of TAP-Win32 is not the problem, this you can leave 
blank, if you have only one TAP-Win32.
Finding the name of your real Ethernet adapter for ndis-bridge is the 
problem.

Mostly users don't mix TAP and ndis-bride (or pcap-bridge) in same 
config, or hav only on adapter. That is the main problem here.
Yes we can add an exclude of TAP-Win32 in the ndis auto probing. It is 
not simple, but would be doable. Than the auto probing would hand on the 
next adapter that is not working, for example WLAN.
Of curse we can "die" the config parser, if we find such broken 
combination. But we can not catch all users misconfigurations.

Yes, it is unsafe, and we have changed very often the name detection 
(substring and so). Auto probing was added as last option for simple 
users. If you have only one adapter (tap, ndis or pcap), than it works. 
Bridging does not work out of the box, if you have more as one network 
adapters configured in the coLinux. So, if you use more as one, please 
give it a name.
The same problem you would have for two or more TAP-Win32. If you have 
installed a second TAP-Win32, you must give the name in coLinux config.

Please also remember: ndis-bridge or pcap-bridge does not work on all 
network cards. Some cards have problem with checksum. WLAN and WiFI 
cards does never work. So, bridging needs a manual configuration. You 
can not set it up for all users environments automatically.

If you not wish to run network services inside the Linux (Samba-, FTP- 
or Web- server) than you should use SLiRP as outgoing network connection 
to the world, and tuntap locally between Windows and Linux.

-- 
Henry N.

  On 05.08.2010 21:00, Mike Mestnik wrote:
> On 8/5/2010 2:27 PM, Henry Nestler wrote:
>>   On 05.08.2010 17:36, Mike Mestnik wrote:
>>> I finally got this working, using...
>>> # echo -ne 'CoLinuxDriver\0tap0801co\0\0' | hexdump -ve '4/1 "&i1 %3u,"
>>> "\\\n"'
>>>          System::Call "*(&i1  67,&i1 111,&i1  76,&i1 105,\
>>> &i1 110,&i1 117,&i1 120,&i1  68,\
>>> &i1 114,&i1 105,&i1 118,&i1 101,\
>>> &i1 114,&i1   0,&i1 116,&i1  97,\
>>> &i1 112,&i1  48,&i1  56,&i1  48,\
>>> &i1  49,&i1  99,&i1 111,&i1   0,\
>>> &i1   0) i .R1"
>>>          System::Call 'advapi32::CreateServiceA(i r4, t r2, t R7, i
>>> ${SERVICE_ALL_ACCESS}, \
>>>                                                 i R4, i R5, i 0, t R6, n,
>>> n, i $R1, $R2, $R3) i.r6'
>> Hui, what an interesting hack :))

Alternatively you can change the depends with command line tool "sc":

sc config "Cooperative Linux" depend= "CoLinuxDriver/tap0801co"

-- 
Henry N.

  Am 05.08.2010 23:01, schrieb Lars Grundei:
> Hi Henry,
>
> ok now I am a bit confused.

I'm too. - From your bridging the bridge ;-)

> The colinux wiki (http://colinux.wikia.com/wiki/Network) tells me:
>
> "The NDIS driver is new in coLinux 0.7.4. It makes use of the NDIS programming API built into windows. It works in practice exactly like the WinPcap driver, just without third party network drivers. It follows the same syntax in the configuration file as the winpcap driver, just use ndis-bridge instead of pcap-bridge"
>
> And
>
> "The name and mac fields are optional. If you don't specify the name parameter coLinux will use the first TAP device it finds. If you don't specify the MAC address in mac, a random one will be generated (in the range 00:FF:xx:xx:xx:xx)."
>
> The 1st comment can be found in section NDIS (this was new to me). The 2nd comment can be found in section TAP, Installation (this is an old part of the wiki, I remember that from my first colinux contact, wich has been a couple of years ago).
>
> Two NICs are required to create a windows bridge, in my case it seems to be quite logical to use the eth0 and tap0 for this. According to my understanding this means, that you need specify the TAP device if you want to access colinux from the network.
>
> Could you clarify this?

"Windows Bridge" and coLinux "ndis-bridge" are different types of 
networking. Of curse, they works similar.

Some peoples use a "Windows Bridge" between WLAN card and Loopback 
adapter to break out the problem of multiple MAC address on the wireless 
channel.

If you use "ndis-bridge" then it is working like a bridge between your 
real Ethernet card and the adapter on Linux side (eth2 in your case). 
You will add a second MAC on the same adapter and Linux than can send 
and receive packets over this. So, ndis-bridge give one adapter a second 
MAC adresses and a second IP-adresses (on the Linux side). The MAC and 
IP address are *added* to the normal work of Windows network stuff. In 
summary have two MACs and two IP adresses. But, every side (Windows and 
Linux) has only one MAC and one IP address.

Compared with the "Windows Bridge": This will bind two adapters and adds 
an 3rd MAC for the bridge self. The original ipaddress of the both 
adapers are hidden (or removed), and the bridge self becomes a new IP 
address.

TAP-Win32 is a separate network between Linux (guest) and Windows 
(Host). This network is normal not accessable from outside of your Windows.

Now, if you have created a "Windows Bridge" between TAP-Win32 and your 
Ethernet card, than you have mixed the two networks to a big one. If you 
use ndis-bridge on this "Windows Bridge", then you will add the 4th MAC 
to this construct. And I don't understand why you don't use the real 
Ethernet adapter directly?  Maybe it can work. Afraid not efficiently. 
And last you will not use the other end of TAP driver, so the Link is 
permanently down for TAP-Win32. I don't understand why you bridged the TAP?

You have (as I assume):
Windows LAN (MAC1) + Windows TAP-Win32 (MAC2) ==> Windows-Bridge (MAC3)
Windows-Bridge (MAC3) ==> ndis-bridge ==> Linux eth2 (MAC4)

Why not?
Windows LAN ==> ndis-bridge ==> Linux eth2
Windows TAP-Win32 ==> tuntap ==> Linux eth1

Over the ndis-bridge you would have all the traffic between your Linux 
and the world outside of your Windows.
This type of config you can also better configure for firewalls (inside 
Linux and/or Windows), and they are less of network driver layers. 
Windows Bridge is slower as ndis-bridge.

With the additional TAP to eth1, all the traffic between Linux (guest) 
and Windows (host) you have a separate network with separate ip area (!) 
and will never seen on the local network.

Now, if you use ndis-bridge you not need the TAP. You can also access 
your Linux from Windows and via versa over the ndis-bridge. Of curse the 
performance is not the best, because using more hardware stacks, and all 
the traffic from Linux to Windows would also seen on all the other 
networking devices in your local network.

===
The additional options now.

For TAP-Win32 the "name" is optional. If you have only one TAP driver 
installed, then coLinux will find it. The TAP-Win32 driver has a 
specific ID, that coLinux knows and will locate for.

ndis-bridge can use *all* adapters (inclusively TAP and loopback), and 
we need to know what interface is your connection to the world.
If you have only ndis-bridge (no TAP-Win32), then it is really optional.
If you have TAP-Win32 and ndis-bridge configured, then the ndis-bridge 
will some times wrong catch the TAP as your favorite network interface. 
It is rarely and depend on your CPU speed and number of cores. Single 
CPU cores often works slowly, so the TAP will be "link up" many seconds 
after the ndis-bridge has scanned all adapters, and all works perfect. 
On faster CPU and dual cores, the TAP-Win32 can be up before the 
ndis-bridge scans the network. In this case the name should written in 
config.

The default sort order of network adapters is sorted by install date, 
and the last installed adapter is placed on top of the list. So you 
would have typically TAP-Win32, WLAN, on board Ethernet card, Loopback 
adapter.

In my case, I have sorted my network adapters (some there in the menu 
"extras" in network overview) to let find coLinux my TAP all times as 
last adapter, after cable LAN and after WLAN (because WLAN dows not work 
with ndis-bridge).

-- 
Henry N.

2004	Jan	Feb	Mar	Apr	May (100)	Jun (134)	Jul (149)	Aug (123)	Sep (185)	Oct (122)	Nov (59)	Dec (127)
2005	Jan (128)	Feb (233)	Mar (210)	Apr (196)	May (85)	Jun (96)	Jul (76)	Aug (149)	Sep (65)	Oct (78)	Nov (121)	Dec (82)
2006	Jan (249)	Feb (181)	Mar (176)	Apr (156)	May (128)	Jun (102)	Jul (157)	Aug (80)	Sep (42)	Oct (49)	Nov (36)	Dec (42)
2007	Jan (64)	Feb (38)	Mar (45)	Apr (74)	May (26)	Jun (20)	Jul (17)	Aug (12)	Sep (40)	Oct (7)	Nov (14)	Dec (16)
2008	Jan (52)	Feb (49)	Mar (90)	Apr (80)	May (78)	Jun (82)	Jul (25)	Aug (8)	Sep (10)	Oct (11)	Nov (3)	Dec (17)
2009	Jan (12)	Feb (16)	Mar (20)	Apr (14)	May (17)	Jun (10)	Jul (13)	Aug (12)	Sep (21)	Oct (10)	Nov (30)	Dec (1)
2010	Jan (2)	Feb (7)	Mar (22)	Apr (6)	May (33)	Jun (5)	Jul (4)	Aug (38)	Sep (46)	Oct (23)	Nov (9)	Dec (5)
2011	Jan (21)	Feb (27)	Mar (1)	Apr (18)	May (12)	Jun (12)	Jul (10)	Aug (30)	Sep (4)	Oct	Nov (9)	Dec (19)
2012	Jan (26)	Feb (6)	Mar (8)	Apr (7)	May (3)	Jun	Jul (10)	Aug (1)	Sep (18)	Oct (5)	Nov	Dec (1)
2013	Jan (27)	Feb	Mar (11)	Apr (14)	May	Jun (1)	Jul	Aug (7)	Sep	Oct (1)	Nov (2)	Dec
2014	Jan	Feb	Mar	Apr (25)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun (1)	Jul (1)	Aug	Sep (1)	Oct	Nov (2)	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (2)	Sep	Oct	Nov	Dec
2024	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec
2025	Jan	Feb	Mar	Apr	May (2)	Jun	Jul	Aug	Sep	Oct	Nov	Dec

colinux-users Mailing List for Cooperative Linux (Page 17)

Run Linux on Windows or other OSes, natively.

colinux-users — coLinux users mailing list