INTEL 815 + Pentium III

It was fixed in 3.16 and now is back.

update:
not only 4.4... all 4.x versions !
I returned to 3.30 :/

I wonder if this is why Im having trouble getting an openvpn connection to work from a Soekris net4501 to my RB1000? On 4.0, 4.1 and 4.4.

I wonder if this is why Im having trouble getting an openvpn connection to work from a Soekris net4501 to my RB1000? On 4.0, 4.1 and 4.4.

no it is not, RB1000 is PPC, not x86

INTEL 815 + Pentium III

It was fixed in 3.16 and now is back.

update:
not only 4.4... all 4.x versions !
I returned to 3.30 :/

upgrade the BIOS?..

upgrade the BIOS?..

BIOS is the lastest ver but this is not the point.

2.x and 3.x is running without any problems.

see http://forum.mikrotik.com/viewtopic.php ... bios+clock

see http://forum.mikrotik.com/viewtopic.php ... bios+clock

thanks for this....yeap, it's always hardware problem.....
in 3.15 it was a hardware problem too ? no, it was fixed.

it's no hard to figure out that MT is not interested supporting x86 platform becouse of cracking ROS and ROUTERBOARD sale.

But routerboards have poor performance (excluding rb1000 - but there is no mpci )
RB800 have about 60-70% efficiency of INTEL PIII 1000MHz- tested.

it's no hard to figure out that MT is not interested supporting x86 platform becouse of cracking ROS and ROUTERBOARD sale.

not interested? for me, RouterOS on x86 works fine. and if for a few users high-precision clock works faster, and for some of them simple upgrade of BIOS solves the problem (there were posts about that) - then the problem is probably something in hardware

no it is not, RB1000 is PPC, not x86

Yah. But it is a Soekris x86 connecting running MT.

Yah. But it is a Soekris x86 connecting running MT.

If clock runs 10x faster than it should on your Soekris router then answer is yes, it is the reason why OVPN is unable to connect.

it's no hard to figure out that MT is not interested supporting x86 platform becouse of cracking ROS and ROUTERBOARD sale.

not interested? for me, RouterOS on x86 works fine. and if for a few users high-precision clock works faster, and for some of them simple upgrade of BIOS solves the problem (there were posts about that) - then the problem is probably something in hardware

yes, not interested. Insted of writing : Update BIOS... MT should do some test and check if there is any connection with bug in 3.15.

If programmers don't know where problem is , how they can be so sure that the problem is not in ROS ?

2.x and 3.x were ok with the same x86 board.

I have the same problem as well,when i turn a wireless interface to ap bridge the clock is running x10.
Which ruins almost everything bgp timers etc.
I checked so far 3 mobos 2 p4 2.8Ghz with p65 chipset with latest bios update(8ipe1000 ver2&3).
And one ASUS P5QPL-AM with core 2 duo.
All have the same problem.

Instead of coming to your customers and saying its a hardware problem,tell us which motherboard works with your software.
Or do you suggest that i should start buying motherboards until i find one that works ok?

I remind you that it was a bug in the past and you fixed it...
*) updated drivers & kernel - fixed fast clock issue on x86;

Thanks in advance.

why dont you use routerboards ?
or just test your mainboards before putting them into production ??
mt cant test all mainboards on the market if their os runs on them
and simply dont use a ros version that makes problem with your hardware

why dont you use routerboards ?
or just test your mainboards before putting them into production ??
mt cant test all mainboards on the market if their os runs on them
and simply dont use a ros version that makes problem with your hardware

We use routerboards but we run a pretty huge network with a lot of traffic.
So the main backbone needs a lot more horse power than a routerboard can do.
Did i say anywhere that is a production system?We are talking about testing environment.
We already running previous version of mikrotik on that hardware.
I didnt buy new hardware to update to version os 4 and 802.11n,should i?

All those questions have nothing to do with the bug though and i dont get your point really.

I remind you that it was a bug in the past and you fixed it...
*) updated drivers & kernel - fixed fast clock issue on x86;

as far as I can see, it was fixed rather by kernel developers than by MT itself...

why dont you use routerboards ?
or just test your mainboards before putting them into production ??
mt cant test all mainboards on the market if their os runs on them
and simply dont use a ros version that makes problem with your hardware

I have about 50 RBs out there, and am ordering 60-70 more. But I have a few sites with some X86 based boxes I want to use RouterOS on, but dont need to replace the hardware. In my case, I have some devices that I was using my own custom linux based firmware with OpenVPN and they worked fine, but MT says "If it doesnt work, it doesnt work and we cant fix it".

PS: The clock does NOT go 10x as fast on my boxes.... I just thought it might be a similar issue.

as far as I can see, it was fixed rather by kernel developers than by MT itself...

Yea but we are expecting support from mikrotik because we buy software and hardware.

Its like you getting a new car and it has a problem with tires and you go back to seller and he tells
you it's not our problem its a problem with the tires of xxx brand.
I am just trying to say that behind the tree there is a forest with few words.

It has to do with the way that the driver uses the kernel,and starts when you use 802.11n cards in
ap bridge mode in our case.
I have a motherboard like those that have the issue in a link with r52n in client mode and the clock
is fine,if i switch it to ap bridge mode the clock is running.
Ap mode with r52 or cm9 doesnt cause an issue also.
It has to do with the PIT timer that implemented in the driver to the new releases.

P.S In some linux boxes with that similar issue with clock
the clock=pit parameter causes the Linux 2.6 kernel to use a more efficient algorithm to synchronize time.Maybe /system hardware set sourceclock-pit=yes or no ?

I remind you that it was a bug in the past and you fixed it...
*) updated drivers & kernel - fixed fast clock issue on x86;

as far as I can see, it was fixed rather by kernel developers than by MT itself...

yes, but ROS is not free, open source, GPL project so we can't do it by ourself right ?

I meant, MT can't fix it until it's fixed in the Kernel =)

I meant, MT can't fix it until it's fixed in the Kernel =)

clock problem was fixed twice... in 3.16 and major in 3.18 release. it was November 5th, 2008 and January 9th, 2009. No more entries in changelog about updating drivers or kernel.

Chupaka, it was a year ago. Look at the kernel.org changelog. Is't long as toilet paper

Suriesly, I hope that someone form MT crew will try to fix this problem.

clock problem was fixed twice... in 3.16 and major in 3.18 release. it was November 5th, 2008 and January 9th, 2009. No more entries in changelog about updating drivers or kernel.

Chupaka, it was a year ago. Look at the kernel.org changelog. Is't long as toilet paper

Suriesly, I hope that someone form MT crew will try to fix this problem.

Try to set /system hardware set multi-cpu=yes even if it's not smp capable system.
Am thinking that the /system hardware set multi-cpu=no removes all the flags from the boot procedure even sourceclock=pit which is what we need.

It works for me.

clock problem was fixed twice... in 3.16 and major in 3.18 release. it was November 5th, 2008 and January 9th, 2009. No more entries in changelog about updating drivers or kernel.

Chupaka, it was a year ago. Look at the kernel.org changelog. Is't long as toilet paper

Suriesly, I hope that someone form MT crew will try to fix this problem.

Try to set /system hardware set multi-cpu=yes even if it's not smp capable system.
Am thinking that the /system hardware set multi-cpu=no removes all the flags from the boot procedure even sourceclock=pit which is what we need.

It works for me.

Thank you very much. multi-cpu=yes remove the problem without changing hardware

I'm looking forward to new entry in 4.6 changelog.

--
It's always the hardware

I have the same problem with v4.4 on Alix1C1. Changeing multicpu=yes/no doesn't any effect. It is very annoying, because I cann't use v3, I have R52hn in this board.

do you have the latest BIOS?

do you have the latest BIOS?

Yes, I have.

Hello!

same Problem with ASROCK AliveNF6G and AMD AM2.
with 3.30 it go's perfectly, but with 4.0-4.5 not...
latest bios is on it.

Did anyone got response or answer from support@mikrotik.com? I didn't. Probably I should use OpenWRT or something more intelligent than RouterOS to get R52Hn cards working on Alix.

Same in 4.6. Chupaka, try to use OSPF with clocks running 10x. I want to see how you will deal with 4 second router dead interval and 1 second hello and 0.5 second retransmit interval )

I have the same problem with v4.4 on Alix1C1. Changeing multicpu=yes/no doesn't any effect. It is very annoying, because I cann't use v3, I have R52hn in this board.

+1 same situation RB 230(x86)/ Waiting for changelog of 4.7

I have 10x faster clock on uni-cpu x86 (Sempron 2800+ Socket 754) system.

it was fine with 3.30, but it's 10x faster with 4.9.

unfortunately, guess there will be no fix for this:
http://forum.mikrotik.com/viewtopic.php ... bios+clock