Menu
▾
▴
vacm-general
|
From: Ard v. B. <ar...@te...> - 2001-07-24 16:42:14
|
Hi, I'm just wondering if it is correct that EMP is *very* slow... Yes, using ipmi-ctl, it was already slow, but this: ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:refresh:rs0' EMP:22:JOB_STARTED EMP:22:STATUS:ENGAGING EMP:22:STATUS:PROTOCOL_DETECTED EMP:22:STATUS:CONNECTION_ACCEPTED EMP:22:STATUS:DOWNLOADING_FRU EMP:22:STATUS:DOWNLOADING_SDR vash: Nexxus 127.0.0.1 timed out waiting for IPC response real 1m37.677s user 0m0.000s sys 0m0.010s ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:25:JOB_STARTED EMP:22:STATUS:DOWNLOADING_SEL EMP:22:JOB_COMPLETED real 0m31.029s user 0m0.000s sys 0m0.010s Hmmm, a bug in vash? Doesn't it wait for the right job to complete? System setup: The emp module is connected through a portmaster using netdata configuration (==raw) to the emp port of a va2230. ard@c24574:/net/home/ard$ vash -c localhost -u blum -p frub -x 'ipc localhost em p:bmc_info:rs0' EMP:10:JOB_STARTED EMP:10:BMCINFO:1.14:Invalid IANA Number:0.9:1 EMP:10:JOB_COMPLETED Anyway, I wanted to check if it is normal to have to wait, say more than 1 minute, before power_off actually turns it off... Regards, Ard -vacm rookie- van Breemen -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-24 16:49:55
|
Hey Ard, This is not normal.. please run nexxus with -l and send me the output.. you may have a serial concentrator problem (probably latency), causing protocol errors... The only serial concentrator qualified to work with VACM is a Cisco 36xx with 32 port async cards -san -----Original Message----- From: vac...@li... [mailto:vac...@li...] On Behalf Of Ard van Breemen Sent: Tuesday, July 24, 2001 9:42 AM To: vac...@li... Subject: [Vacm-general] Slow EMP handling Hi, I'm just wondering if it is correct that EMP is *very* slow... Yes, using ipmi-ctl, it was already slow, but this: ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:refresh:rs0' EMP:22:JOB_STARTED EMP:22:STATUS:ENGAGING EMP:22:STATUS:PROTOCOL_DETECTED EMP:22:STATUS:CONNECTION_ACCEPTED EMP:22:STATUS:DOWNLOADING_FRU EMP:22:STATUS:DOWNLOADING_SDR vash: Nexxus 127.0.0.1 timed out waiting for IPC response real 1m37.677s user 0m0.000s sys 0m0.010s ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:25:JOB_STARTED EMP:22:STATUS:DOWNLOADING_SEL EMP:22:JOB_COMPLETED real 0m31.029s user 0m0.000s sys 0m0.010s Hmmm, a bug in vash? Doesn't it wait for the right job to complete? System setup: The emp module is connected through a portmaster using netdata configuration (==raw) to the emp port of a va2230. ard@c24574:/net/home/ard$ vash -c localhost -u blum -p frub -x 'ipc localhost em p:bmc_info:rs0' EMP:10:JOB_STARTED EMP:10:BMCINFO:1.14:Invalid IANA Number:0.9:1 EMP:10:JOB_COMPLETED Anyway, I wanted to check if it is normal to have to wait, say more than 1 minute, before power_off actually turns it off... Regards, Ard -vacm rookie- van Breemen -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ _______________________________________________ Vacm-general mailing list Vac...@li... http://lists.sourceforge.net/lists/listinfo/vacm-general |
|
From: Ard v. B. <ar...@te...> - 2001-07-24 17:31:59
|
On Tue, Jul 24, 2001 at 09:59:56AM -0700, San Mehat wrote: > This is not normal.. please run nexxus with -l and send me the output.. Thanks, I needed to here it is not normal :) > you may have a serial concentrator problem (probably latency), causing > protocol errors... I've seen those errors, when I used telnet as the protocol.... But now: ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:3:JOB_STARTED vash: Nexxus 127.0.0.1 timed out waiting for IPC response real 0m50.113s user 0m0.000s sys 0m0.000s You have mail in /home/ard/Mail/.inbox ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:6:JOB_STARTED EMP:3:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:3:JOB_COMPLETED real 0m38.015s user 0m0.000s sys 0m0.000s ard@c24574:/net/home/ard$ And in the log (used /var/log/vacm.log, since that is timestamped): [18:52:08][VACM] 2.0.5 Nexxus daemon (Build Jun 24 2001 23:21:50) [18:52:08][Nexxus] Standard Out Logging Enabled [18:52:08][Nexxus] Identified 11 modules [18:52:08][Nexxus] [Vasenet][0.5][VASENET][Zac Sprackett (za...@va...)] [18:52:08][Nexxus] [VA1000][1.1][VA1000][Jerry Katzung (ka...@va...)] [18:52:08][VA1000] Failed to open /dev/va1000_smbus: device does not exist! [18:52:08][Nexxus] [Sysstat][0.1][SYSSTAT][San Mehat (net...@va...)] [18:52:08][Nexxus] [BayTech][2.0][BAYTECH][Zac Sprackett (zsp...@va...)] [18:52:08][Nexxus] [EMP][2.0][EMP][San Mehat (net...@va...)] [18:52:08][Nexxus] [ICMP ECHO][1.0][ICMP_ECHO][San Mehat (net...@va...)] [18:52:08][Nexxus] [QUANTA][0.1][QUANTA][Zac Sprackett (za...@va...)] [18:52:08][Nexxus] [rsh][2.0][RSH][Dean Johnson (dt...@sg...) & Zac Sprackett (zsp...@va...)] [18:52:08][Nexxus] [SBT2][0.1][SBT2][Zac Sprackett (za...@va...)] [18:52:08][Nexxus] [SERCON][2.0][SERCON][San Mehat (net...@va...)] [18:52:08][Nexxus] [msc][2.0][MSC][Dean Johnson (dt...@sg...)] [18:52:08][SERCON] Unable to lookup 'c24574.telegraafnet.nl'. Connections unavailable (Unknown host) <snipped 17 more of these SERCON> [18:52:09][EMP] Thread rs0 protocol detected [18:52:13][EMP] Thread office protocol unavailable (Connection timed out) [18:53:04][Nexxus] Logging user blum in on client 17 from 127.0.0.1 [18:53:54][Nexxus] Logging user blum out on client 17 from 127.0.0.1 [18:54:01][Nexxus] Logging user blum in on client 17 from 127.0.0.1 [18:54:39][Nexxus] Logging user blum out on client 17 from 127.0.0.1 I've seen errors: [11:25:29][EMP] Thread rs0 received corrupt EMP data field (us 0x49, them 0x48) [11:25:29][EMP] Thread rs0 data c4 2c 10 20 78 11 00 10 00 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 48 a5 [11:25:30][EMP] Thread rs0 received corrupt EMP data field (us 0x45, them 0x44) [11:25:30][EMP] Thread rs0 data c4 2c 10 20 7c 11 00 10 00 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 a5 [11:25:30][EMP] Thread rs0 received corrupt EMP data field (us 0x45, them 0x44) [11:25:30][EMP] Thread rs0 data c4 2c 10 20 7c 11 00 10 00 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 a5 But these were the typical telnet instead of raw errors. And the following: ard@c24574:/net/home/ard$ sudo lsof -c emp.loose|grep pm2-0|wc -l 56 Is there a way to (runtime) limit the number of threads started, so that I can strace, and see what exactly is going on? The build I use is the wakkerma build: http://people.debian.org/~wakkerma/vacm > The only serial concentrator qualified to work with VACM is a Cisco 36xx > with 32 port async cards > -san Hmmm, the cyclades ts2000 sounds interesting. If we are able to strip software that is not needed (like radius and stuff like that), and implement some emp daemon, it could nicely handle all those emp ports, and serial consoles... (http://www.cyclades.com/products/stdalone/ts1_2000.htm) But then again, it might all be cyclades proprietery software that runs on linux... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: <sa...@va...> - 2001-07-24 17:39:09
|
On Tue, Jul 24, 2001 at 07:31:53PM +0200, Ard van Breemen wrote: > Is there a way to (runtime) limit the number of threads started, so that > I can strace, and see what exactly is going on? > The build I use is the wakkerma build: > http://people.debian.org/~wakkerma/vacm > > > The only serial concentrator qualified to work with VACM is a Cisco 36xx > > with 32 port async cards > > -san > Hmmm, the cyclades ts2000 sounds interesting. If we are able to strip > software that is not needed (like radius and stuff like that), and > implement some emp daemon, it could nicely handle all those emp ports, > and serial consoles... > (http://www.cyclades.com/products/stdalone/ts1_2000.htm) > But then again, it might all be cyclades proprietery software that runs > on linux... > Nope, all of the software that runs on the Cyclades TS1000 (16 port) and TS2000 (32 port) term servers is open source. The main piece of software that manages the ports is portslave or pslave. If you are curious the flash image of exactly what is on them is available for download from the Cyclades ftp site. -- Steven A. DuChene sdu...@mi... Racked Solutions Architect & Program Manager lin...@mi... |
|
From: San M. <net...@va...> - 2001-07-24 18:19:04
|
We had done some initial investigating into the cyclades product to see if this exact thing could be done... basically it appears that the box is too underpowered to drive all the ports with the EMP state machine.. We noticed that the machine was so underpowered that it was taking a few seconds for a connection to be acknowledged as closed by the box.. so the port that was being listened() on was showing a connection *well* after shutdown() was called on the socket.... not good... The cyclades box looks to be a good solution for serial console redirection.. but it just doesn't look like it has the horsepower for managing the EMP state machine.... -san -----Original Message----- From: vac...@li... [mailto:vac...@li...] On Behalf Of sa...@va... Sent: Tuesday, July 24, 2001 10:39 AM To: Ard van Breemen Cc: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Tue, Jul 24, 2001 at 07:31:53PM +0200, Ard van Breemen wrote: > Is there a way to (runtime) limit the number of threads started, so that > I can strace, and see what exactly is going on? > The build I use is the wakkerma build: > http://people.debian.org/~wakkerma/vacm > > > The only serial concentrator qualified to work with VACM is a Cisco 36xx > > with 32 port async cards > > -san > Hmmm, the cyclades ts2000 sounds interesting. If we are able to strip > software that is not needed (like radius and stuff like that), and > implement some emp daemon, it could nicely handle all those emp ports, > and serial consoles... > (http://www.cyclades.com/products/stdalone/ts1_2000.htm) > But then again, it might all be cyclades proprietery software that runs > on linux... > Nope, all of the software that runs on the Cyclades TS1000 (16 port) and TS2000 (32 port) term servers is open source. The main piece of software that manages the ports is portslave or pslave. If you are curious the flash image of exactly what is on them is available for download from the Cyclades ftp site. -- Steven A. DuChene sdu...@mi... Racked Solutions Architect & Program Manager lin...@mi... _______________________________________________ Vacm-general mailing list Vac...@li... http://lists.sourceforge.net/lists/listinfo/vacm-general |
|
From: Ben R. <br...@we...> - 2001-07-24 18:32:20
|
I was wondering if the change from making hardware and the neding of support would stop the development of VACM? Is this the case? Our are you a part of the SourceForge area that is staying in the realigned VALinux? I do not want to begin using the software if it is going away.... Ben Ricker System Administrator Wellinx.com |
|
From: 'Ard v. Breemen' <ar...@te...> - 2001-07-25 12:13:13
|
On Tue, Jul 24, 2001 at 11:29:06AM -0700, San Mehat wrote: > We had done some initial investigating into the cyclades product to see > if this exact thing could be done... basically it appears that the box > is too underpowered to drive all the ports with the EMP state machine.. Hmmm, that is weird: I guess that with a 50MHz ppc, it is very easy to control 32 serial ports. > We noticed that the machine was so underpowered that it was taking a few > seconds for a connection to be acknowledged as closed by the box.. so > the port that was being listened() on was showing a connection *well* > after shutdown() was called on the socket.... not good... Well, time to look at the source code then.... Hmmm, hands start itching.. It sounds like somebody has programmed the box to generate interrupts for every port. This results on 19.2k (the emp speed) in 1920 interrupts per port per second, that is about 61440 interrupts... Even a pentium will not be able to handle that. > The cyclades box looks to be a good solution for serial console > redirection.. but it just doesn't look like it has the horsepower for > managing the EMP state machine.... Just a question of software.... Like in the old days. Then they did the same, just with less hardware :). > -san > Nope, all of the software that runs on the Cyclades TS1000 (16 port) and > TS2000 (32 port) term servers is open source. The main piece of software > that manages the ports is portslave or pslave. If you are curious the > flash image of exactly what is on them is available for download from > the Cyclades ftp site. Yes! Cool! Now I need the Cyclades itself, and unfortunately we already have serial console systems, so I cannot request one for my work :(... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-25 15:14:09
|
Hey Ard, The first thing I did when I got my cyclades was open it up :) Ted Tso, the author of the Linux TTY/serial driver layer also had a look.. It appears they use a *ton* of semi-standard UARTS which are connected to an ISA bus on the system... fine for normal bursted serial flow.. but really awfull for lots of single byte I/O which is what the EMP state machine calls for rather heavily.... This has been a common problem with serial concentrator vendors.... in any event, playing in the kernel may be difficult as I understand their serial driver itself is not open source.... other than that I agree that it may be just a matter of software, however I just don't have the bandwidth to work on yet another piece of serial hardware (I'm currently working on preliminary IPMI 1.5 over LAN support) If you do decide to take this on, let me know.. I'd be happy to provide whatever EMP related assistance I can... -san -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 5:13 AM To: San Mehat Cc: sa...@va...; vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Tue, Jul 24, 2001 at 11:29:06AM -0700, San Mehat wrote: > We had done some initial investigating into the cyclades product to see > if this exact thing could be done... basically it appears that the box > is too underpowered to drive all the ports with the EMP state machine.. Hmmm, that is weird: I guess that with a 50MHz ppc, it is very easy to control 32 serial ports. > We noticed that the machine was so underpowered that it was taking a few > seconds for a connection to be acknowledged as closed by the box.. so > the port that was being listened() on was showing a connection *well* > after shutdown() was called on the socket.... not good... Well, time to look at the source code then.... Hmmm, hands start itching.. It sounds like somebody has programmed the box to generate interrupts for every port. This results on 19.2k (the emp speed) in 1920 interrupts per port per second, that is about 61440 interrupts... Even a pentium will not be able to handle that. > The cyclades box looks to be a good solution for serial console > redirection.. but it just doesn't look like it has the horsepower for > managing the EMP state machine.... Just a question of software.... Like in the old days. Then they did the same, just with less hardware :). > -san > Nope, all of the software that runs on the Cyclades TS1000 (16 port) and > TS2000 (32 port) term servers is open source. The main piece of software > that manages the ports is portslave or pslave. If you are curious the > flash image of exactly what is on them is available for download from > the Cyclades ftp site. Yes! Cool! Now I need the Cyclades itself, and unfortunately we already have serial console systems, so I cannot request one for my work :(... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: 'Ard v. Breemen' <ar...@te...> - 2001-07-25 15:52:35
|
On Wed, Jul 25, 2001 at 08:24:15AM -0700, San Mehat wrote: > The first thing I did when I got my cyclades was open it up :) Ted Tso, Of course :) > the author of the Linux TTY/serial driver layer also had a look.. It > appears they use a *ton* of semi-standard UARTS which are connected to > an ISA bus on the system... fine for normal bursted serial flow.. but ugh... > really awfull for lots of single byte I/O which is what the EMP state > machine calls for rather heavily.... Hmmm.... Actually it should be workable... A kernel "thread" should poll all emp ports (I guess half of them will be emp, the other half will be serial console) in a single poll stroke. That is about 1920 poll's per second no matter the number of ports. Any active port will result in the emp-daemon being scheduled at most 1920 times per second, no matter the number of ports. In a single stroke the emp-daemon should be able to respond to all traffic, and queue any incoming data from the emp ports. That is 500 microseconds for kernel-interrupt, task switch, and handling of data. Of course, the task switch only happens when it was not already running. After that, a more normal threaded and buffered approach can be used. > This has been a common problem with serial concentrator vendors.... in > any event, playing in the kernel may be difficult as I understand their > serial driver itself is not open source.... other than that I agree that Grrrr. Although, the CDK is a .i386.rpm, but it looks like it contains source. > it may be just a matter of software, however I just don't have the > bandwidth to work on yet another piece of serial hardware (I'm currently > working on preliminary IPMI 1.5 over LAN support) Eh, that is ipmi with default lan support? > If you do decide to take this on, let me know.. I'd be happy to provide > whatever EMP related assistance I can... Well, I first have to search for a cyclades first... I will probably not be able to obtain one :( , so I will try to think out my bike computer some more. (bike sample http://www.alleweder.nl ) (Ever seen a bike computer that show median speed instead of that stupid average?) -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-25 17:06:12
|
Hey Ard, IPMI 1.5 is the latest and greatest IPMI management goop but it works completely over LAN via UDP... kind of cool.. no timing requirements.. fairly strong authentication... etc... Bike computer? -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 8:52 AM To: San Mehat Cc: sa...@va...; vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Wed, Jul 25, 2001 at 08:24:15AM -0700, San Mehat wrote: > The first thing I did when I got my cyclades was open it up :) Ted Tso, Of course :) > the author of the Linux TTY/serial driver layer also had a look.. It > appears they use a *ton* of semi-standard UARTS which are connected to > an ISA bus on the system... fine for normal bursted serial flow.. but ugh... > really awfull for lots of single byte I/O which is what the EMP state > machine calls for rather heavily.... Hmmm.... Actually it should be workable... A kernel "thread" should poll all emp ports (I guess half of them will be emp, the other half will be serial console) in a single poll stroke. That is about 1920 poll's per second no matter the number of ports. Any active port will result in the emp-daemon being scheduled at most 1920 times per second, no matter the number of ports. In a single stroke the emp-daemon should be able to respond to all traffic, and queue any incoming data from the emp ports. That is 500 microseconds for kernel-interrupt, task switch, and handling of data. Of course, the task switch only happens when it was not already running. After that, a more normal threaded and buffered approach can be used. > This has been a common problem with serial concentrator vendors.... in > any event, playing in the kernel may be difficult as I understand their > serial driver itself is not open source.... other than that I agree that Grrrr. Although, the CDK is a .i386.rpm, but it looks like it contains source. > it may be just a matter of software, however I just don't have the > bandwidth to work on yet another piece of serial hardware (I'm currently > working on preliminary IPMI 1.5 over LAN support) Eh, that is ipmi with default lan support? > If you do decide to take this on, let me know.. I'd be happy to provide > whatever EMP related assistance I can... Well, I first have to search for a cyclades first... I will probably not be able to obtain one :( , so I will try to think out my bike computer some more. (bike sample http://www.alleweder.nl ) (Ever seen a bike computer that show median speed instead of that stupid average?) -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-24 18:16:09
|
Hey Ard, As I suspected, it looks like you're having a serial protocol issue.. The reason that only the cisco boxes are qualified as a *network* based connectivity method for EMP are that they have below 1 ms round trip latency on single byte transactions on their raw ports... The EMP protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will timeout the byte (and sometimes the fame). It is VERY difficult to recover a frame when this occurs, so we end up having to do nasty re-synchronizing which doesn't always work... I would advise going to a rocketport connectivity solution since its much cheaper than the cisco method... -san -----Original Message----- From: Ard van Breemen [mailto:ar...@te...] Sent: Tuesday, July 24, 2001 10:32 AM To: San Mehat Cc: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Tue, Jul 24, 2001 at 09:59:56AM -0700, San Mehat wrote: > This is not normal.. please run nexxus with -l and send me the output.. Thanks, I needed to here it is not normal :) > you may have a serial concentrator problem (probably latency), causing > protocol errors... I've seen those errors, when I used telnet as the protocol.... But now: ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:3:JOB_STARTED vash: Nexxus 127.0.0.1 timed out waiting for IPC response real 0m50.113s user 0m0.000s sys 0m0.000s You have mail in /home/ard/Mail/.inbox ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:6:JOB_STARTED EMP:3:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:3:JOB_COMPLETED real 0m38.015s user 0m0.000s sys 0m0.000s ard@c24574:/net/home/ard$ And in the log (used /var/log/vacm.log, since that is timestamped): [18:52:08][VACM] 2.0.5 Nexxus daemon (Build Jun 24 2001 23:21:50) [18:52:08][Nexxus] Standard Out Logging Enabled [18:52:08][Nexxus] Identified 11 modules [18:52:08][Nexxus] [Vasenet][0.5][VASENET][Zac Sprackett (za...@va...)] [18:52:08][Nexxus] [VA1000][1.1][VA1000][Jerry Katzung (ka...@va...)] [18:52:08][VA1000] Failed to open /dev/va1000_smbus: device does not exist! [18:52:08][Nexxus] [Sysstat][0.1][SYSSTAT][San Mehat (net...@va...)] [18:52:08][Nexxus] [BayTech][2.0][BAYTECH][Zac Sprackett (zsp...@va...)] [18:52:08][Nexxus] [EMP][2.0][EMP][San Mehat (net...@va...)] [18:52:08][Nexxus] [ICMP ECHO][1.0][ICMP_ECHO][San Mehat (net...@va...)] [18:52:08][Nexxus] [QUANTA][0.1][QUANTA][Zac Sprackett (za...@va...)] [18:52:08][Nexxus] [rsh][2.0][RSH][Dean Johnson (dt...@sg...) & Zac Sprackett (zsp...@va...)] [18:52:08][Nexxus] [SBT2][0.1][SBT2][Zac Sprackett (za...@va...)] [18:52:08][Nexxus] [SERCON][2.0][SERCON][San Mehat (net...@va...)] [18:52:08][Nexxus] [msc][2.0][MSC][Dean Johnson (dt...@sg...)] [18:52:08][SERCON] Unable to lookup 'c24574.telegraafnet.nl'. Connections unavailable (Unknown host) <snipped 17 more of these SERCON> [18:52:09][EMP] Thread rs0 protocol detected [18:52:13][EMP] Thread office protocol unavailable (Connection timed out) [18:53:04][Nexxus] Logging user blum in on client 17 from 127.0.0.1 [18:53:54][Nexxus] Logging user blum out on client 17 from 127.0.0.1 [18:54:01][Nexxus] Logging user blum in on client 17 from 127.0.0.1 [18:54:39][Nexxus] Logging user blum out on client 17 from 127.0.0.1 I've seen errors: [11:25:29][EMP] Thread rs0 received corrupt EMP data field (us 0x49, them 0x48) [11:25:29][EMP] Thread rs0 data c4 2c 10 20 78 11 00 10 00 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 48 a5 [11:25:30][EMP] Thread rs0 received corrupt EMP data field (us 0x45, them 0x44) [11:25:30][EMP] Thread rs0 data c4 2c 10 20 7c 11 00 10 00 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 a5 [11:25:30][EMP] Thread rs0 received corrupt EMP data field (us 0x45, them 0x44) [11:25:30][EMP] Thread rs0 data c4 2c 10 20 7c 11 00 10 00 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 44 a5 But these were the typical telnet instead of raw errors. And the following: ard@c24574:/net/home/ard$ sudo lsof -c emp.loose|grep pm2-0|wc -l 56 Is there a way to (runtime) limit the number of threads started, so that I can strace, and see what exactly is going on? The build I use is the wakkerma build: http://people.debian.org/~wakkerma/vacm > The only serial concentrator qualified to work with VACM is a Cisco 36xx > with 32 port async cards > -san Hmmm, the cyclades ts2000 sounds interesting. If we are able to strip software that is not needed (like radius and stuff like that), and implement some emp daemon, it could nicely handle all those emp ports, and serial consoles... (http://www.cyclades.com/products/stdalone/ts1_2000.htm) But then again, it might all be cyclades proprietery software that runs on linux... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: 'Ard v. Breemen' <ar...@te...> - 2001-07-25 13:21:38
|
On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > As I suspected, it looks like you're having a serial protocol issue.. > The reason that only the cisco boxes are qualified as a *network* based > connectivity method for EMP are that they have below 1 ms round trip > latency on single byte transactions on their raw ports... The EMP > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > timeout the byte (and sometimes the fame). It is VERY difficult to But how is the byte acked? What happens with modems? If I hook up a modem, the round trip will probably exceed that 2 ms due to compression and other stuff. We are after all talking about almost 4 byte-times. > recover a frame when this occurs, so we end up having to do nasty > re-synchronizing which doesn't always work... But if it needs to re-synchronize, it would tell me, right? It does not say anything about sync... (Hmmm, see the debugging commented out, recompiling...) > I would advise going to a rocketport connectivity solution since its > much cheaper than the cisco method... Well, another good solution would be a real power-boot :). -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: 'Ard v. Breemen' <ar...@te...> - 2001-07-25 14:28:51
|
On Wed, Jul 25, 2001 at 03:21:29PM +0200, 'Ard van Breemen' wrote: > On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > > As I suspected, it looks like you're having a serial protocol issue.. > > The reason that only the cisco boxes are qualified as a *network* based > > connectivity method for EMP are that they have below 1 ms round trip > > latency on single byte transactions on their raw ports... The EMP > > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > > timeout the byte (and sometimes the fame). It is VERY difficult to > But how is the byte acked? What happens with modems? If I hook up a > modem, the round trip will probably exceed that 2 ms due to compression > and other stuff. We are after all talking about almost 4 byte-times. Allright... Debugging using tcpdump and ethereal. My system send a byte to the portmaster. 1.37 ms later the portmaster acks. 53 ms later the portmasters sends a packet containing data. Usually 1 byte as a reaction from my system. But sometimes up to 29 bytes. But always 53 ms... As if something was nagging... Or at least some timer seems to be involved... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: 'Ard v. Breemen' <ar...@te...> - 2001-07-25 15:09:33
|
On Wed, Jul 25, 2001 at 04:28:45PM +0200, 'Ard van Breemen' wrote: > On Wed, Jul 25, 2001 at 03:21:29PM +0200, 'Ard van Breemen' wrote: > > On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > > > As I suspected, it looks like you're having a serial protocol issue.. > > > The reason that only the cisco boxes are qualified as a *network* based > > > connectivity method for EMP are that they have below 1 ms round trip > > > latency on single byte transactions on their raw ports... The EMP > > > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > > > timeout the byte (and sometimes the fame). It is VERY difficult to > > But how is the byte acked? What happens with modems? If I hook up a > > modem, the round trip will probably exceed that 2 ms due to compression > > and other stuff. We are after all talking about almost 4 byte-times. > Allright... > Debugging using tcpdump and ethereal. > My system send a byte to the portmaster. > 1.37 ms later the portmaster acks. > 53 ms later the portmasters sends a packet containing data. > Usually 1 byte as a reaction from my system. But sometimes up to 29 bytes. > But always 53 ms... > As if something was nagging... Or at least some timer seems to be involved... It get's worse: Enabled all emp debugging (like DEBUG_TRANS), the download still takes long, but other actions are currently fast. Refresh of the node will fail the first time. As if it tries to reconnect with a connection still open. The second time it works (maybe the connection is closed due to the failure of opening it :) ). Anyway: ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:124:JOB_STARTED EMP:124:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:124:JOB_COMPLETED real 0m0.818s user 0m0.000s sys 0m0.000s ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:127:JOB_STARTED EMP:127:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:127:JOB_COMPLETED real 0m0.528s user 0m0.000s sys 0m0.000s The .5 s is median. It either takes .5 s or .8 s. The download_log takes about the same time, but that is probably cached? -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: San M. <net...@va...> - 2001-07-25 15:33:40
|
The download log code erases the log as it downloads it.. the log in the hardware is meant to be a mailbox and not general storage.. so everytime an entry is downloaded it is deleted, so once the log download is complete, the log should be empty until something puts an entry in it :) -san -----Original Message----- From: vac...@li... [mailto:vac...@li...] On Behalf Of 'Ard van Breemen' Sent: Wednesday, July 25, 2001 8:09 AM To: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Wed, Jul 25, 2001 at 04:28:45PM +0200, 'Ard van Breemen' wrote: > On Wed, Jul 25, 2001 at 03:21:29PM +0200, 'Ard van Breemen' wrote: > > On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > > > As I suspected, it looks like you're having a serial protocol issue.. > > > The reason that only the cisco boxes are qualified as a *network* based > > > connectivity method for EMP are that they have below 1 ms round trip > > > latency on single byte transactions on their raw ports... The EMP > > > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > > > timeout the byte (and sometimes the fame). It is VERY difficult to > > But how is the byte acked? What happens with modems? If I hook up a > > modem, the round trip will probably exceed that 2 ms due to compression > > and other stuff. We are after all talking about almost 4 byte-times. > Allright... > Debugging using tcpdump and ethereal. > My system send a byte to the portmaster. > 1.37 ms later the portmaster acks. > 53 ms later the portmasters sends a packet containing data. > Usually 1 byte as a reaction from my system. But sometimes up to 29 bytes. > But always 53 ms... > As if something was nagging... Or at least some timer seems to be involved... It get's worse: Enabled all emp debugging (like DEBUG_TRANS), the download still takes long, but other actions are currently fast. Refresh of the node will fail the first time. As if it tries to reconnect with a connection still open. The second time it works (maybe the connection is closed due to the failure of opening it :) ). Anyway: ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:124:JOB_STARTED EMP:124:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:124:JOB_COMPLETED real 0m0.818s user 0m0.000s sys 0m0.000s ard@c24574:/net/home/ard$ time vash -c localhost -u blum -p frub -x 'ipc localhost emp:chassis_status:rs0' EMP:127:JOB_STARTED EMP:127:CSTATUS:YES:NO:NO:NO:NO:YES:NO:NO:NO:NO:NO:YES:NO:NO:NO EMP:127:JOB_COMPLETED real 0m0.528s user 0m0.000s sys 0m0.000s The .5 s is median. It either takes .5 s or .8 s. The download_log takes about the same time, but that is probably cached? -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ _______________________________________________ Vacm-general mailing list Vac...@li... http://lists.sourceforge.net/lists/listinfo/vacm-general |
|
From: San M. <net...@va...> - 2001-07-25 15:32:18
|
Ard, This has been a common problem with network T/S's... when receiving data from the serial port, they wait for either a minimum number of bytes to arrive, or for a maximum timeout before sending the data over the network... these devices are normally optimized for streaming protocols (as they should be), and obviously it doesn't work with us... That's one of the reasons I like cisco's.. their RAW port *really* is raw... one byte of data from the serial port ends up sending a frame... which is why they work.... I also tried other network terminal servers like the Digi EtherLites, various Livingston beasties, etc... -san -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 7:29 AM To: San Mehat Cc: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Wed, Jul 25, 2001 at 03:21:29PM +0200, 'Ard van Breemen' wrote: > On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > > As I suspected, it looks like you're having a serial protocol issue.. > > The reason that only the cisco boxes are qualified as a *network* based > > connectivity method for EMP are that they have below 1 ms round trip > > latency on single byte transactions on their raw ports... The EMP > > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > > timeout the byte (and sometimes the fame). It is VERY difficult to > But how is the byte acked? What happens with modems? If I hook up a > modem, the round trip will probably exceed that 2 ms due to compression > and other stuff. We are after all talking about almost 4 byte-times. Allright... Debugging using tcpdump and ethereal. My system send a byte to the portmaster. 1.37 ms later the portmaster acks. 53 ms later the portmasters sends a packet containing data. Usually 1 byte as a reaction from my system. But sometimes up to 29 bytes. But always 53 ms... As if something was nagging... Or at least some timer seems to be involved... -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: Dean J. <dt...@ub...> - 2001-07-27 04:41:53
|
San Mehat wrote: > Ard, > > This has been a common problem with network T/S's... when receiving data > from the serial port, they wait for either a minimum number of bytes to > arrive, or for a maximum timeout before sending the data over the > network... these devices are normally optimized for streaming protocols > (as they should be), and obviously it doesn't work with us... > That's one of the reasons I like cisco's.. their RAW port *really* is > raw... one byte of data from the serial port ends up sending a frame... > which is why they work.... I also tried other network terminal servers > like the Digi EtherLites, various Livingston beasties, etc... > -san > Bill Sparks (js...@sg...) was able to get the SGI version of the EtherLite working reasonably well with the EMP. It was the latest hardware with the latest firmware, and probably some prevailing tailwind involved, but it worked well. I don't know how it would fare under a load, but it successfully handled bringing an SGI 1200 up and down for many hours without a failure. -Dean |
|
From: San M. <net...@va...> - 2001-07-27 17:34:16
|
Ahhh excellent.. however I had found that with more nodes things start to break down with EMP protocol.. simply pinging around on the network a bit could cause problems.. (not good) TGIF -san -----Original Message----- From: Dean Johnson [mailto:dt...@ub...] Sent: Thursday, July 26, 2001 9:41 PM To: San Mehat Cc: 'Ard van Breemen'; vac...@li... Subject: Re: [Vacm-general] Slow EMP handling San Mehat wrote: > Ard, > > This has been a common problem with network T/S's... when receiving data > from the serial port, they wait for either a minimum number of bytes to > arrive, or for a maximum timeout before sending the data over the > network... these devices are normally optimized for streaming protocols > (as they should be), and obviously it doesn't work with us... > That's one of the reasons I like cisco's.. their RAW port *really* is > raw... one byte of data from the serial port ends up sending a frame... > which is why they work.... I also tried other network terminal servers > like the Digi EtherLites, various Livingston beasties, etc... > -san > Bill Sparks (js...@sg...) was able to get the SGI version of the EtherLite working reasonably well with the EMP. It was the latest hardware with the latest firmware, and probably some prevailing tailwind involved, but it worked well. I don't know how it would fare under a load, but it successfully handled bringing an SGI 1200 up and down for many hours without a failure. -Dean |
|
From: Dirk W. <di...@re...> - 2001-08-14 18:09:27
|
Hi all, what kind of Baytech powerstrip do i need for controlling it with vacm? Is the one with the serial one just fine (e.g. RPC-28) or do i need a ethernet connection as well? can somebody please enlighten me ;-). the thing which confuses me a little bit though is that the docu doesn't say for the serial Baytech what (BayTech)port the machine is hooked up to: ---- FORMAT: BAYTECH:CONFIGURATION:<NODE_ID>:<DEVICE_ADDRESS> RESPONSES: JOB_STARTED JOB_ERROR:(errno string) JOB_COMPLETED FIELDS: <DEVICE_ADDRESS> - Either a serial port or the address of a port on a terminal server in the form of hostname-port --- but the for reboot it says: --- FORMAT: BAYTECH:PORT_REBOOT:<NODE_ID>:<PORT_ID> --- or does it mean that i only can use vash and not hoover powercycling the machine? thx, ~dirkw |
|
From: Dirk W. <di...@re...> - 2001-08-15 19:06:42
|
Hi, i wasn't quite clear with my objective. what i wanted is: configure a baytech powerstrip so that with hoover i can select my client and press reset, as i am used to do with EMP capable clients. 3 questions: a is that possible? b what baytech strip do i need for that c (if answer(a)=yes): what do i need to do to set it up? thx! ~dirkw On Tue, 14 Aug 2001, Dirk Wetter wrote: > > Hi all, > > what kind of Baytech powerstrip do i need for controlling it with > vacm? Is the one with the serial one just fine (e.g. RPC-28) > or do i need a ethernet connection as well? can somebody please > enlighten me ;-). > the thing which confuses me a little bit though is that the docu > doesn't say for the serial Baytech what (BayTech)port the machine is > hooked up to: > > ---- > FORMAT: > BAYTECH:CONFIGURATION:<NODE_ID>:<DEVICE_ADDRESS> > RESPONSES: > JOB_STARTED > JOB_ERROR:(errno string) > JOB_COMPLETED > FIELDS: > <DEVICE_ADDRESS> - Either a serial port or the address of a port on > a terminal server in the form of hostname-port > --- > > but the for reboot it says: > > --- > FORMAT: > BAYTECH:PORT_REBOOT:<NODE_ID>:<PORT_ID> > --- > > or does it mean that i only can use vash and not hoover powercycling the > machine? > > thx, > ~dirkw > > > _______________________________________________ > Vacm-general mailing list > Vac...@li... > http://lists.sourceforge.net/lists/listinfo/vacm-general > |
|
From: San M. <net...@va...> - 2001-07-25 15:29:45
|
Ard, Basically an EMP request frame looks like this: 0xa0 <-- frame start 0x20 <-- EMP slave address 0xxx <-- LUN and NetFn 0xxx <-- checksum 0x64 <-- EMP application slave address 0xxx <-- sequence number (goes up by 4) 0xxx <-- Command 0xx1 <-- Command arg byte 1 0xx2 <-- Command arg byte 2 0xxn <-- Command arg byte n 0xxx <-- checksum 0xa5 <-- Frame end Now after sending each byte you have to wait for an ack (0xa8) from the hardware.. When the hardware ack's a byte, the *next* byte MUST arrive Within 2ms, otherwise the hardware thinks there has been a communications error and *SILENTLY* discards the entire frame. This is one of the large problems with resynchronization... if we send a few bytes of the command within the proper 2ms window, then for one reason or another we send one byte *after* the window, then the remote firmware will silently toss the frame. We of course don't know this has happened so as per the EMP spec, when the byte we last sent does not receive an ack, we resend it and it is acked.. this continues until we send the frame end character at which point the remote hardware sends us an error saying the command we sent is invalid because the frame it received was truncated due to the fact that it tossed the first few bytes due to a timeout. Now... take that behavior, and add the fact that every 2 seconds of realtime, no matter what is going on the port, the hardware will send a PING frame (EMP_ACTIVE), and things get even more messy... You can have a look at emp_driver.c to see just how messy things can get... Basically, H/W S/W flow control would of made this whole thing a lot nicer.. but what can you do... sigh.. As for the resynchronizing stuff, if you have the right debugging compiled in you may see a msg like this: Driver %s calling detect_protocol because resync required or something... ;) For more information on this in terms of debugging, make sure that TRANS_DEBUG is defined in emp_driver.c (transport debug), and run it... you might want to log it or something as this will generate a lot of data when running on multiple nodes -san -----Original Message----- From: 'Ard van Breemen' [mailto:ar...@te...] Sent: Wednesday, July 25, 2001 6:21 AM To: San Mehat Cc: vac...@li... Subject: Re: [Vacm-general] Slow EMP handling On Tue, Jul 24, 2001 at 11:26:11AM -0700, San Mehat wrote: > As I suspected, it looks like you're having a serial protocol issue.. > The reason that only the cisco boxes are qualified as a *network* based > connectivity method for EMP are that they have below 1 ms round trip > latency on single byte transactions on their raw ports... The EMP > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > timeout the byte (and sometimes the fame). It is VERY difficult to But how is the byte acked? What happens with modems? If I hook up a modem, the round trip will probably exceed that 2 ms due to compression and other stuff. We are after all talking about almost 4 byte-times. > recover a frame when this occurs, so we end up having to do nasty > re-synchronizing which doesn't always work... But if it needs to re-synchronize, it would tell me, right? It does not say anything about sync... (Hmmm, see the debugging commented out, recompiling...) > I would advise going to a rocketport connectivity solution since its > much cheaper than the cisco method... Well, another good solution would be a real power-boot :). -- <ar...@te...> Telegraaf Elektronische Media http://wwwijzer.nl http://leerquoten.monster.org/ http://www.faqs.org/rfcs/rfc1855.html Let your government know you value your freedom. Sign the petition: http://petition.eurolinux.org/ |
|
From: Dean J. <dt...@ub...> - 2001-07-27 04:32:43
|
San Mehat wrote: > Hey Ard, > > As I suspected, it looks like you're having a serial protocol issue.. > The reason that only the cisco boxes are qualified as a *network* based > connectivity method for EMP are that they have below 1 ms round trip > latency on single byte transactions on their raw ports... The EMP > protocol requires a MAXIMUM latency of 2ms per byte.. otherwise it will > timeout the byte (and sometimes the fame). It is VERY difficult to > recover a frame when this occurs, so we end up having to do nasty > re-synchronizing which doesn't always work... > > I would advise going to a rocketport connectivity solution since its > much cheaper than the cisco method... The Comtrol Interchange VS1000 seems to also work. -Dean |
Thanks for helping keep SourceForge clean.
X