Thursday, March 27, 2008

Connectix cat6 component tolerances

We recently completed a data job for a big customer and when they came to plug up their VOIP 'phones they discovered a problem with the cat6 cabling/wallboxes we installed. After lots of head-scratching and pulling the modules apart I discovered that there has been a batch change - notice the different colour of PCB. The newer modules (yellow PCB) have a stronger spring to close the dust cover (second picture).


Now, when you plug in certain brands of pre-made patch cords the stronger spring pushes up on the RJ45 and forces it back out of the socket by a small amount - maybe only a milimeter. This is enough to make the connection unreliable.


It thankfully seems to be a batch issue as only a few of the thousand modules I bought seem affected!.

Labels: , ,

Thursday, March 06, 2008

10-gig Ethernet article from TVB Europe magazine

After the sessions at the Broadcast Live show (last month) and the Root6 Tech Breakfast (this week) my rambings about ten gig ethernet and OM3 fibre appear in TVB Europe magazine - see the article here.
Cabling for high-speed networks seems to be my shtick at the moment.
You may need to do Save As - for some reason my Linux box ain't serving up MIME types properly!

Labels: , ,

Tuesday, March 04, 2008

10 gig ethernet and Force10

This morning was the first of the Root6 tech breakfasts where I had to wax lyrical about cat7 and OM3 fibre. I think it went down well. I got to chat to the guys from Force10 networks who we've recently started to represent in the infrastructure/chassis-switch market. They score over Cisco et al. in that the latency across their backplanes is considerably lower (typ. figure of 300nS for full stateful inspection and packet forwarding). The told me an interesting thing about Cisco - apparently none of their current 1gig and 10gig port offerings are non-blocking designs! They can't guarantee that their switches won't max-out under heavy load and start turning packets away! I couldn't believe it - if you've paid for n number of gig or 10-gig ports (which, at 10-gig is still around $1k per port) you expect n x 10gig of backplane bandwidth - not with Cisco. Everyone else - Extreme Networks, The Foundry, and of course Force10 promise this, but not Cisco.

Just imagine if Mr Probel sold you a video router and you discovered that it couldn't maintain 1.5Gbits of video per port for all ports simultaneously - you send it to the workshop for repair!

Labels: ,

Thursday, February 07, 2008

Common problems with ethernet networks

The ugly face of the overdraft is stalking me and so I'm back onto freelancing in the evenings. I was at an interesting place last night - a film effects company who were having big trouble with their network. Windows shares that would sporadically not mount, name resolution that sometimes didn't work and file transfer speeds that often dropped to just a few kbits-1. They are running a mixed Linux/Windows/Mac network and so it seemed like the problems would be due to some underlying infrastructure issues. They have a Windows server running Active Directory with DHCP, DNS and WINS resolution - the reason for both WINS and DNS is that their render manager only talks NetBIOS names and won't resolve via DNS. Here are the problems I found;

  • Sharepoints is an OS-X app that makes sharing directories over Samba as easy as under Windows - it seems to add little extra value compared to using the Sharing control panel. One little gotcha is that there is a check box marked 'announce as master browser' which on all the machine I found was selected. Looking in the Windows server system error log showed numerous entries (many every minute) where the server was complaining about all the Macs trying to assume master-browse status. Unchecking sorted this and name resolution for the Windows machines improved markedly.
    Now, there is a well-established order for Windows browse master allocation - server, workstations etc. There will be at least one Master Browser on a workgroup/domain and one Backup Browser for every 32 systems in that workgroup/domain. This means that in a domain/workgroup with fewer than 32 systems, there will be one Master and one Backup Browser. One more Backup Browser will be added for every 32 systems. This is accomplished by the Master Browser telling a Potential Browser to become a Backup Browser. The browse service maintains an up-to-date list of domains, workgroups, and computers and provides this list to applications when requested. For example, a W2K user might see this list when they select a workgroup to which the user's computer does not belong from within the "My Network Places" application. "Browse lists" can also be displayed by using the "net view" command. The list can contain the names of domains, workgroups, and computers that run file and printer sharing services. These computers can be Windows for Workgroups (WFW) through XP machines, including both workstations and server, or any Samba shares that are in that subnet as well. Both domain and workgroup (if present) resources will be shown in these browse lists. So, having numberous Macs trying to bum-rush the show as browse masters is not a great idea!

  • The network seemed to have a good beginning - a couple of HP ProCurve 2800 and an 1800 all uplinked over 2gig fibre via SFPs. I discovered that one of the uplink ports was dead and so someone had 'got it going' with a cat6 between them. However - the failing port was intermitent and so periodically you'd get connectivity via two routes and a packet storm would ensue! I switched the SFP to a working port, re-established the fibre and removed the cat6 interconnect and it suddenly got a lot more solid! The HP ProCurve manager software is very good for identifying this kind of trouble.

  • This network had grown 'organically' (sic!) which means that where they needed more ports (an extra render-farm, for example) they had thrown in a Tottenham Court Road special - Netgear/DLink/etc. This had happened one time too often and so there were several pieces of equipment that were separated by four (or even five) ethernet switches - you run into the problem of the protocol retry period being less than the propigation delay through that many nodes. I nominated one of the ProCurves and made sure that all the switches in the place hung off that (and hence no two machines had more than three switches between them) and the servers all hung off that ProCurve.

So - there you go - I got home tired but really happy that I'd managed to sort some things out. I don't know how some of these little effects houses manage without engineers. I really like getting back to trouble-shooting and maintenance (and hopefully clearing down some debt!).

Labels: , ,

Monday, December 03, 2007

10 gig ethernet over cat5e?

It's a question a couple of people have asked me now. It is even the case that Intel and Alcatel have suggested they may have a line-conditioning chip that will allow it over sub-10m distances, but my response is;
The problem become apparent when you consider that 10gig over cat7 runs at 600Mhz (strictly speaking you need 22Ghz to carry 10gig data - Nyquist limit and all that) but 10gigE uses QAM and OFDM modulation techniques to achieve this. Now, cat5e cable is flat'ish to 100Mhz and cat6 to 250Mhz.

By the time gigE came along it was cheap enough to incorporate a QAM16 modulator and OFDM encoder on the network card and so they could start getting away with sub-Nyquist bandwidths. 10gigE takes this to another level with QAM64 modulation (similar to aDSL and DVB-T) and a verterbie decoder. But, even then it really does need the 650Mhz of bandwidth to achieve 10gig speeds over 100m of cable - the guys at Tyco reckoned that doing 10 gigE over cat5e would only ever be feasible over sub-10m distances, even with heavy-duty line-conditioning chips.
The strength of an IP stack is that it will tolerate lots of line noise and packet failures - the network card may reports that it's seeing the 10gig heartbeat but if you're dropping half your packets is it worth it?

Labels: ,

Wednesday, November 21, 2007

DataCentre Design & Build

I went to a very good lecture at my institute last night - here are some of the things that struck me;

  • UK data-centres currently consume about 4% of the electricity generated in this country. This is set to rise to 7% by 2010 and then about one percent per year on current rates of growth.
  • If you look at a kW-hour as generated and measure how much of that makes it to the processor you see that there are modest losses in transmission and sub-stations, but by the gates of the data-centre you still have 80%. However, once you've gone through distribution and (particularly) UPSes and then the mass-market PSUs that most servers still ship with you are down to about 10% of original power by the time you get to the motherboard.
  • Virtualisation hasn't yet penetrated into UK data-centres as much as it should have - this is particularly important because the average server is typically consuming only 15% of processor cycles. I did write about VM Ware previously.
  • Having spent time at VNSL's data-centre in Stratford a few days recently I've been thinking about efficiently those guys do cooling and power-distribution - see previous post here.

Labels: ,

Friday, August 31, 2007

Test outputs from the Fluke DTX1800

This is a single page of the test results from Simon's mamouth test of all six-hundred cat7 circuits at one of our current jobs. You won't believe how much data that machine collects on each feed!

Labels: ,

Thursday, May 24, 2007

100 Gigabit Ethernet

We're just getting to grips with ten-gig ethernet (and the plethora of copper & fibre connectors and standards!) and I notice the Ethernet Alliance are talking about the road to one-hundred gigabit. They have an interesting paper here and if you need a catch-up on where ethernet came from look at the slides of their history presentation.

Labels: ,

Monday, January 09, 2006

NET-IOM Ethernet/Web I/O Board

Occasionally you see a solution that is so cool you have to buy one just to play with it! This card is a little webserver (and it can send emails!) with ethernet, 16 x digital i/o (GPI ins and relay closure for o/p in tele talk!) and 4 analogue i/o channels. It also has an RS232 port. All of these are accessible across a LAN or the internet (if you configure a static route through your router). Most significantly is that two of them will talk to each other and so extending button pushes, lights, buzzers, temperature probes, alarms etc. between buildings is possible. The best bit (for me!) is that you can extend a serial connetion across the internet and according to the manual you can tweak latency so that for time-critical applications (controlling a VTR via the P2 protocol) you could optimise it.
I shall report when I've got it in and tested it.

Labels:

Sunday, September 25, 2005

More on power-over-ethernet
I was keeping my eye on the IEE802.2 spec for POE (see a previous post here) and was a tad bemused for the reasons I'd mentioned in April - however, the new 802.2af version is now out and is a specification that embraces gigabit and hence putting the packets as a carrier on a DC voltage - each of the four pairs can supply 13W at an operating potential of 45v. It's a similair arrangement to how your Sky LNB works or how power is sent down a camera triax. Better than this though, and for legacy compatability, a network switch must first "test the water" by measuring the impedance of each pair, and if the device at the other end looks as if it's POE compliant it can start ramping a voltage. It has to test a few more times before it can lift it up to the 45v level and so should never wind up frying old 100baseT NICs or even other deives that are using the structured cabling (telephones etc.) - a few more details on the excellent Power over Ethernet website.

Labels:

Thursday, May 06, 2004

No-name gig ethernet card at Maplin for £17! Not the kind of thing to rely on for work - but a great way to start moving your home network to gigabit. They have stock in the Tottenham Court Road shop (for all you Soho boys and girls!)

Labels:

Monday, November 24, 2003

RS422 over cat5 cable
I cable a lot of TV facilities and the tendency nowadays is to use the ubiquitous cat5 data cable for carrying everything that doesn't require a better grade of cable. RS422 for machine control used to be universally carried on Star Quad cable but now cat5 does the job - here is the pinout I have settled on:

  • I avoid the blue pair because that is often used to analogue voice and if you mis-patched you may wind up terminating a data pair in a low impedance.
  • The brown pair often carries power in POE (Power Over Ethernet) implementations and if you mis-patch the sending switch sees a low impedance and shuts off the current.
  • The orange and green pair carry the Tx and Rx pairs as per ethernet (which expects to see a 110 ohm termination).
That's why I do it thus!

Labels: ,


 
Phil's technical blog