New Parma IP location (24.116.39.206) seems to be unreachable via telnet or SNMP and therefore not reachable by TMS.

 
Confirmed PRI dial in problem to MCU in test with Parma. Parma would only connect on one channel when dialing this direction but could connect on all six when dialing to Ag. MCU dialing to Parma connected on all six channels.

After booting the MCU Parma and Poky were able to dial in.

While a simple restart of the MCU seems to have solved the trouble I am still a little worried as we have had this PRI trouble for a little while and we have done reboots in that time and the trouble has either not cleared up or has recurred. Since there does not seem to be any trouble connecting PRI sites to sites other than the MCU e.g. Parma to Ag went through fine, the problem may be between the Model 60 and the MCU or the MCU itself.

 
Tested the ISDN connection from Poky to the MCU this morning. Poky could only connect with two channels when they dialed in but we got all six channels when we dialed to them.

 
For today's PlSc 501 in the MCU Aberdeen connected at only 64 kbps. They did not dial in until 11:29 so I did not have a chance to try to reconnect them before class started.

 
Pocatello could not dial in ISDN to ME 412 (MCU) today. Only one channel would connect and the rest would not bond. Had to bring them in IP.

 
I downloaded and installed GripLite on the Ed103 computer. It seems to be working okay. I did not use the former install much, being more of a button-pushing type operator, so I am not sure if it is the same as it was before. A desktop icon should show up for all logins, otherwise you should be able to get to it via the start menu.

I like having this machine on XP! Be sure to update your Favorites and links lists. Let me know if you want a list of codecs to import.

 
Ed103 has its computer back (yeah!), but we will need to have Griplite re-installed. I am sending this into cyberspace in the hope that someone out there knows how to do it, if not, then let me know and I will figure it out (assuming we have the software somewhere)..

 
Today's ME 412 (EO, IF2, ISU): Idaho Falls only connected at 320 kbps (ISDN on-net). I tried to disconnect IF site to do a reconnect but the call would not clear even with a Disconnect All command. I rebooted the MCU and was able to rebuild the class and it started on time.

Also about ME 412: The Pocatello connection will be ISDN until we can improve the reliability of the IP connection, per Casey . Casey will be dialing in. I will make the necessary changes in the MCU assignment.

 
Good Morning!! Child Labor Law Meeting, 9:00 am - 9:45 am 3/11/04. Here is a log of issues I saw. Event started, off campus sites were introducing themselves, Aberdeen and Parma flashed a green screen. When Aberdeen was speaking, Parma disconnected, I brought them back in...
9:15 Parma flashed green screen, Moscow speaking, all mic were muted except Idaho Falls.
9:35 Parma flashed green screen, Moscow speaking, all mics were muted. In between 9:35 and 9:40, Parma asked to 2 questions the audio was consistantly broken. 9:40, green screen flash in Aberdeen when Parma speaking. 9:43, Parma asked another question, audio was normal, no green screen flash.. Conference ended! During this conference I did not switch from Enhanced CP. You're all are doing a great job! I appreciate YOU!! Paula

 
Mike--That seems similar to the problem I noted on March 1st. I wonder if there is something wrong with the PRIs or how we have them configured to work with the MCU, though Don says that CdA2 is 'on net' and should not be affected by PRI trouble.

 
Had a problem with CDA2 in the CALS Leadership meeting this morning. When they first connected, all we got from them was a green screen. I disconnected and reconnected, and the picture cleared up.

As the meeting continued this morning, I noticed that Aberdeen and Parma also had brief periods (fractions of a second) where the screen flashed to green.

 
For a while today it seemed that changes made to UI's and ISU's packet shapers had yielded some improvement to the latency graph but now it is not so clear. There was the usual latency spike yesterday, though it was later than usual and not as severe as most days.

The mcu is back registered with the gatekeeper.

 
Mark says that ITS has made some changes to our packet shaper. Also said that the gigapop reports that it has fixed the instability issues it was experiencing.

 
Today's LOC meeting with mcu connection to Pocatello had to go ISDN because the IP connection would not go through. Casey says that the trouble was to do with their packet shaper and that he did not believe it was related to the other ISU IP troubles we are having.

 
FYI--Dan and I have still not recieved access to TMS. I don't think either of us really cares, but it could come in handy and save somebody a little hassle if we need to change conference times.

 
It looks to me like there may be an improvement in packet loss with the MCU unregistered. It looks like loss on Wednesday, while the MCU was registered, was about 3%. Today, unregistered, it is just under 1%. Of course I can't tell where any of them are being dropped, or whether it is related to the daily ISU 'latency storm' blowing out on the net. Also, I think the improvement may be natural variation--some days it will be better or worse than others.

The meeting going on now with CNR-ISU (not through the MCU) is experiencing a high degree of packet loss and extremely poor video. The call rate has been stepped-down to 352 kbps by the codecs.

 
This morning's SmokePing graph showed less than 0.2% packet loss and about 60 ms rtt from ISU to UI but the 30 hour graph shows a 'latency storm' running from about 9 a.m. to 9 p.m., peaking about when we were testing yesterday. Casey reports that this is a typical daily occurrence, though yesterday's was the worst since last Thursday, the first day that was graphed, but still not nearly so bad. As I write, the graph does seem to be ramping up again.

 
Just completed a short test call with Casey with the MCU unregistered from the gatekeeper. The packet loss did seem to be reduced compared to some of the tests we have done recently but the video was not improved. We plan on testing later during the daily 'latency storm'.

 
I unregistered the MCU from the gatekeeper this morning and had Brian run another MTR traceroute. The new trace showed 0% packet loss on the last two hops. These two had shown as much as 20% loss over the last few days.

I will re-register the MCU at 10:00 and will unregister again at 11:30. I want to see if there are any corresponding data points on the SmokePing graph.

 
Did a test call to Bozeman in an effort to isolate the packet loss to ISU while Mark sniffed packets (that's the kind of guy he is). During that call there was considerable packet loss and jitter, so much that the call rate eventually got down to 128 kbps. The connection eventually dropped but that could have been Montana hanging up. Mark saw increasing delay on the traceroutes behind the gigapop. ISU SmokePing showed 4.4% packet loss and over 100 ms rtt to the UI MCU during the test.

Currently the ISU SmokePing graph shows 8.73% packet loss and over 100 ms rtt going from Poky to the UI MCU. For comparison it shows about a 60 ms rtt and 0.14% packet loss to the WSU INRA MCU.

 
Had another problem with a Dell computer tonight. Tried to connect a Dell laptop to the Tandberg in Ed 301, but once it was connected, the Tandberg itself would not recieve the signal. Everything seemed to be connected correctly, and I checked all the wires twice, but nothing would bring up the screen (yes, I used the function keys to switch the output). The screen would flash on the laptop when I tried to switch outputs, but it never made it over to the Tandberg. I remember Daryl and I having a similar problem with a Dell in Ag 62.

 
More on ISU-Pocatello IP connection: Following our test on Friday, Casey talked to Randy and was told to procede with testing to try and identify the problem. Casey asked Brian to test further. Brian ran MTR, which combines traceroute and ping functions from a Linux box. According to the MTR report Brian sent me there was no packet loss until the last two hops to the UI MCU, which are on the UI campus. I passed that info on to Mark. He found that the MCU was not in the border traffic shaping policy as high priority video. After that was changed, Brian ran MTR again and there was no real improvement in the packet loss at the MCU or the hop before it.

While this does seem to indicate a problem with the UI network, I am not sure if ping and traceroute data is comparable to video traffic. I think video packets may behave differently than ping/traceroute packets. I would like to do our own tests to see what this might mean.

ISU's SmokePing report from their MCU to ours is currently showing a median ping RTT average of 69.5 ms and average packet loss of 0.14%, considerably less packet loss than the 5% to 8% reported by MTR.

 
Our control room computers are being infested with spyware. These nasty programs are loaded when you install certain programs. The CNR computer was slammed pretty hard, possibly when a free program called 'Clock Sync' was loaded. The Ed computer was possibly infected from a program called WinAmp. Not only are these spys and advertising popup programs very annoying they also adversely impact computer performance, making browsers, etc. behave in unexpected ways and stealing system memory. Spyware is also hard to get rid of once it is installed--it took 2 hours to get CNR relatively clean. Please do not install any programs on our computers.

 
In today's Ag Processes meeting the three sites that were coming in on the PRI would all occasionally simultaneously glitch with green or black video. Parma, Aberdeen and Sandpoint every few minutes would 'green glitch' then come back. Audio seems to be affected as well. At one point Parma audio did not come back and I did a reconnect to clear that problem.