Friday, May 22, 2009

Leaf Networks - better than Hamachi


I've written about Hamachi as a lightweight VPN solution in the past and for a year or more I used it every day to access files at home and provide an in to friends and relatives machines who I do tech support for. Not having to worry about opening ports on routers etc. is fantastic but recently Hamachi got unreliable and now I can't make it work for more than a few weeks without upgrading (due to their new license) which is a pain as suddenly you can't VNC to the machine you need to upgrade!
Anyhow - I've been playing with Leaf for a few days and it seems a much more solid solution. It also has the advantage of having routing built in so you can use it to expose other machine on the target network over the VPN tunnel. As well as allowing LAN play across the internet for XBox games that don't support Windows Live I imagine any embedded devices you don't want to expose to the world over an open port would be usable from wherever you've got your laptop (insecure wireless in a coffee shop, for example).

Labels: ,

Saturday, February 21, 2009

Tomato firmware

The tomato has got to be the best food-stuff ever - sliced tomato brightens up any sandwich and grilled tomato sets off any cooked meal. Where would Italian cookery be with it? If God made anything better he must have kept it for himself....
Anyhow - in the same way the best open-source router firmware is Tomato v.1.23 - I picked up a Buffalo WHR-G54S router on eBay for £14 and blew in the new firmware. It offers everything you'd expect from a corporate-grade firewall in a tiny package - QoS, all maner of MAC, IP, port & protocol routing and filtering as well as the ability to run C-Shell scripts on an event or times basis. I took me a couple of hours to set up but my network seems snappier, wireless devices connect quicker and I can monitor (in realtime) bandwidth usage by machine or protocol.

Labels:

Wednesday, October 22, 2008

Netvue - business class IP TV system

I went to a very impressive demo at Sony BMG today - they have an Exterity-based office IP-TV system as provided/configured/integrated by NetVue. They seemed to have really got it right. The system is based on IGMP multicast over IP which relies on IGMP-compliant switches (think Cisco 3750 or equivelent HP ProCurve). Essentially it means that only the streams that are being watched are present on the network and then only the data is present on those segments with active clients.
Set-top boxes are tiny and around the £250 mark. The PC client comes in at £35 per seat.
What I found to be the really clever side of it was the TV gateway which takes DVB-T multiplexes and strips out all the transport streams and makes them available. So, with their 1u chasis you can expose all six FreeView Muxes (55 stations?) on the network for around £8k - to build an RF-system with similar abilities would cost many times this and the pictures would look awful (I know - I've built a few!). If you need to hang a video device (Sky STB, DVD player, etc.) their STB & PC client can both back-propagate IR control.
As mentioned - I kept getting the feeling that 'they've done this right' - it's a very complete/robust solution. I like the idea that when they can avoid it they don't re-encode the video and assume the clients can replay MPEG-2 transport streams (or in the case of the HD STB H.264 transport streams).

I can't wait to spec one of these!

Labels: , ,

Friday, August 29, 2008

Gaping hole opened in Internet's trust-based BGP protocol

My interest in BGP grows;

....Pilosov and Kapela, however, have found and demonstrated a way to intercept communication and then forward it back along to its original intended recipient. This is normally impossible; having established himself as the most direct router for a given address, any data the hijacker attempts to follow is promptly returned. Pilosov and Kapela bypass this issue by prepending the IP address they feed to certain routers. Prepending refers to attaching additional numbers to their own advertised route, in order to ensure that certain routers reject it. Once a router has rejected their address, the hacker feeds the data to be forwarded on to it. The data is processed and sent to where the router thinks it should go, which means it ends up forwarded on to its intended recipient.

Labels: ,

Saturday, July 05, 2008

Building Reliable Networks with the Border Gateway Protocol

By Iljitsch van Beijnum 0-596-00254-8

Kip very kindly bought me this book after having seen a previous post and it is a very good read. If you want to understand how big networks talk to each other then BGP is the way to go and Van Beijnum treats it as a way to cover all WAN protocols current practices.

Labels: ,

Thursday, June 26, 2008

Snakeoil salesmen target networking!

I would not have believed it unless I saw it with my own eyes! A five-hundred dollar cat5e cable - for audiophile application!
It has the obligatory signal direction markers - is that for the Tx or the Rx pair?! Like all non-DC electrical signals there are as many electrons going one way as the other!

Thanks Matt - you sick man!

Labels: ,

Saturday, June 14, 2008

Three recent internet failures

I'm very interested on how WANs (and even the ultimate WAN - the internets) work. Border Gateway Protocol is one of the areas I know little about but would love to have a chance to explore. With the in mind I wanted to write about three interesting events that happened over the last year that highlight some of the inner workings of the Internet.

  • Pakistan's YouTube takedown happened when Pakistan's government ordered it blocked because of offensive material, apparently a video depicting the cartoons about Muhammad that had been posted in a Danish newspaper. Some reports have said the video featured several minutes of a film made by Dutch politician Geert Wilders, an outspoken critic of Islam.
    A spokesman for the Pakistani embassy said on Monday that the order to block access to YouTube came from the highest levels of the government. It would have been passed along to Pakistan's Electronic Media Regulatory Authority and then to Pakistan's telecom authority, the spokesman said, which in turn would have issued the formal order to the Internet providers.
    Pakistan Telecom responded by broadcasting the false claim that it was the correct route for 256 addresses in YouTube's 208.65.153.0 network space. Because that was a more specific destination than the true broadcast from YouTube saying it was home to 1,024 computers, within a few minutes traffic started flowing to the wrong place.
    A timeline created by Renesys, which provides real-time monitoring services, says that it took about 15 seconds for large Pacific-rim providers to direct YouTube.com traffic to the Pakistan ISP, and about 45 seconds for the central routers on much of the rest of the Internet to follow suit.
    YouTube took countermeasures within minutes, first trying to reclaim its network by narrowing its 1,024 broadcast to 256 addresses. Eleven minutes later, YouTube added an even more specific additional broadcast claiming just 64 addresses--which, under the Border Gateway Protocol, is more specific and therefore should overrule the Pakistani one. Over two hours after the initial false broadcast, Pakistan Telecom finally stopped.
    How could this have been prevented? First, Pakistan Telecom shouldn't have broadcast to the entire world that it was hosting YouTube's IP addresses. Second, Hong Kong-based PCCW could have recognized the broadcast as false and filtered it out.

  • Digg's Torrent-server attack started with a SYN flood aimed at Revision3's BitTorrent tracker clogged the company's tubes and brought down all of its web services. The traffic logs indicated that the network was getting slammed by over 8,000 packets every second. Revision3 tracked the source of the packets and discovered that the attack originated from MediaDefender - a company that provides Bittorrent poisoning services to big media. TWiT on 2nd June has very good coverage of the events, particularly Jim Louderback's insights.

  • Amazon's recent DDOS attack happened on 6th June - Amazon.com was taken down by a distributed denial-of-service attack that struck the Web site's load-balancing system. The DDoS attack bypassed AWS services like Amazon's S3, striking directly at the heart of Amazon's business. It's unclear how Amazon fought off the attack, which struck roughly at 10:20 AM.

The interesting thing about these three incidents is that they don't conform to the traditional hacker-led attack. In the case of YouTube it was big-government, in the case of Revision3 it was big-media and in the case of Amazon it was big-money trying to 'short' their stock. No doubt that none of the perpetrators will ever have to answer for their misdeeds.

Labels:

Sunday, March 30, 2008

OpenDNS

OpenDNS is a free DNS resolution service. It provides the following two recursive nameserver addresses for public use, mapped to the nearest operational server location:


* 208.67.222.222 (resolver1.opendns.com)
* 208.67.220.220 (resolver2.opendns.com)

Often it's higher performing than your ISP's own DNS servers, that tend to be unwanted stepchildren of ISPs. DNS is not a very sexy thing for them to be offering, so they tend to be hosted on the oldest/slowest servers. The real killer feature of OpenDNS is the filtering they offer, which being at the domain-name resolution stage means you can point your router at them and your whole network is protected from phishing, porn and other dark back-waters of the internet.
For ages I ran a proxy server inside my network but it got very tedious and since I've offloaded every other function (mail serving etc.) this seems like a good replacement (and no software to run in my network).

Labels: ,

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: , ,

Wednesday, January 30, 2008

Broadcast Live 2008

We're exhibiting at Earl's Court 2 this week - swing by our stand J50 if you're there and have a beer/smoothie.
One of the best displays I've ever seen is the EyeVis 4k LCD we have demoing the output of the 4k Clipster from DVS. I had to set it up - it needs four DVI feeds!
Anyhow - I'm giving a seminar on Thursday on ten gigabit ethernet - you can grab my presentation here.
Do Save As.. as my server isn't offering up proper MIME info at the moment - stand by!

Labels: ,

Wednesday, December 19, 2007

What you get from another systems integrator!

Thanks for Paula at MPC for sending me this one - it's the comms room of a big, well known TV facility.
Tony and my boys nearly feinted when I showed them this.....

Labels: , ,

Wednesday, December 12, 2007

What a hard dance the SaMBa is!

I recently installed Leopard on a late-model G4 for use as a media machine at home and I have to say it works really well (I wish the step-upgrade to Vista had been as nice!) but I've discovered a few things about how Samba/SMB/CIFS works under various OSes;
  1. Leopard gives you a warning when you share a folder over SMB - something like 'your password will be stored and shared as plain-text' - very good I thought, warning you about the problem of pre-Kerberos SMB (v.3 SMB in Windows?) - but no - it ONLY supports Kerberos authentication! This effectively limits you to using only post Win2k boxes to access Leopard. My PDA can't pluck files off Leopard and the Mac can't get files off my Linux-based NAS.
  2. When you mount an SMB share from Leopard using an XP machine (jn the case of my MediaPortal PVR) it will only accept the first authentication approach - i.e if you're not logged into the Windows box with an account that Leopard recognises then you can't supply any other credentials. Since Leopard can't integrate into a Windows domain this is a major drop-off.
  3. Vista won't talk to pre-V2 Samba servers - apparently the rumour that SMB 2 in Vista was engineered specifically to 'f**k with Samba' might be true! Listen to the edition of Floss Weekly (in the title link) - you'll learn more about Samba/SMB/CIFS than you currently know.

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: ,

Tuesday, August 21, 2007

Fluke DTX-1800 cable analyser

The Fluke DTX-1800 Cable Analyzer provides a bandwidth 900 MHz that supports video distribution, Class F and 10 Gigabit Ethernet. Its transmissive LCD display with backlight makes for easy viewing. Its rotary knob makes learning easy and operation simple, keeping you in the know as to what test mode is selected. The USB port facilitates high-speed transfer of data.

This is tester that we've just bought to test the big 10-Gig ethernet project we're doing - see a previous post here.

Testing for ten gigs over copper isn't yet ratified so we use a slightly ad-hoc method;
10 Gig testing should be performed to ISO11801 ClassEA Channel (not permanent link) testing using PiMF 600 patch cables. Tyco recommend using a set of 2M patch leads for 500 tests and keeping them referenced to the tested ports.
On the DTX setup it will be ISO ClassEa Ch 25N1255. This is the latest draft standard for 10G cabling system performance. There is currently no permanent link standard to work to as the permanent link requires component performance parameters which have not been defined yet.

I'll post an example XML-export in the next couple of days.

Labels: ,

Tuesday, July 17, 2007

cat6a, cat7 and all that 10gig stuff!

I spent a day at Tyco in Stanmore doing some training on the newest types of ten gigabit network cables. Since there is no ratified standard for ethernet at this data rate (even though both Intel and Cisco have products) everyone is referring to it with different terminology. The Germans refer to the cable as cat7, the Americans as cat6a (the 'a' is augmented) and Tyco (who seem to have the biggest portfolio so far) as XG-10gig cable.
We spent the morning going over the physics of it all - the new cable is a 600Mhz channel and by QAM64 and OFDM (which I blogged about recently) signal processing techniques they can get ten gigabits per sec down one hundred metres of cable. If you use earlier cat5e or cat6 cable you are pretty much limited to sub-30m lengths.
The differences in cable and termination are sufficiently marked with respect to vanilla cat6 as to require different tools and techniques and everything is specified (even down to the sub-50N of force you can apply when pulling it into ducts). They seem to have woken up to the fact that relying on common-mode rejection as the only means of noise reduction is flawed and consequently this new cable is double-screened - the pairs are individually shielded and there is an overall screen. This is why the cable is also referred to as PIMF (pairs in metal foil).
Reasons for differences;

  • Near-end cross talk is dramatically reduced by virtue of the new ends and termination tool. When properly terminated the twisted pair and shield is maintained to within a couple of millimeters of the pin on the connector. You could never achieve this with traditional punch-down methods.

  • Alien cross-talk is minimised by the over-shield - cat5e and cat6 never really enjoyed this advantage.

  • Inter-pair cross-talk is minimised by the foil shield around each of the pairs.
There is no RJ45 plug that can be crimped on - you can only buy pre-made patch cords. Panel to panel wiring is the only termination type permitted on site.
This has to be the future of data-centre wiring - we're currently doing a job that involved 600-odd circuits like this (and it's in a visual-effects company), however - I never imagined I'd have gigabit at home and it can only be a couple of years before ten-gig ethernet is ubiquitous.

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: ,

Saturday, October 28, 2006

Hamachi rocks!

I was aware of Hamachi as a personal VPN solution last year and knew that security guru Steve Gibson rates it (check out his podcast on the subject here) - now I've been trying to get my Windows server at home to do the VPN-server thang but it seems so tempremental - and this is borne out by trawling the news-groups. Any change to the network config makes the routing service fail and this week I had the audacity to upgrade one of the network cards for gigabit and I've not been able to get the MS VPN to come back up - so (like every other network protocol that machine serves) I've discovered that a third-party solution is invariably more stable/faster than the one that Microsoft provides.

http://www.hamachi.cc/

Labels:

Thursday, March 23, 2006

IP-Packet sniffer screensaver

I found this screensaver that is a network packet sniffer - it puts the packet header and a few dozen bytes from the packet on screen as a fountain-style screensaver - very nice and consuming to watch.
It did puzzle me a bit as we are on a switched network here at Root6 and yet it seems to see things that are on separate segments - I hope it isn't doing some sort of ARP-poisoning or man-in-the-middle type attacks to get the data!

I often notice packets from our Cisco 'phone system whizz past as well as web and email headers. This, along with Steve Gibson's Security Now podcasts really have filled in a few holes in my appreciation of how IP moves over both ethernet and internets.

Labels:

Friday, January 20, 2006

Fibre cabling for editing workstations

Another article for the Root6 catalogue

As our need for higher speed data transfer increases and the advantages of shared storage become apparent to post-producers – high definition television places a requirement on disk space several times that of standard definition and big productions require editors to collaborate on shows. With all this in mind it is no surprise that we’re leaving SCSI behind and our Avids are increasingly using cheaper commodity-based FireWire storage for low-end DV-based work and fibre-channel for larger SAN (“Storage Area Network”)-based collaborative workflows. At Root6 we’ve seen an increase in SAN sales over the last year with Facilis’s Terrablock product line hitting the price/performance spot for many users.
With this as the background, we now do a significant amount of fibre installations as people look to future proof their facilities. The differences between traditional data fibre and the “young turks” who operate SANs, are significant and the lack of appreciation of those differences has caused many an installation gaff for integrators who haven’t taken the time to appreciate those details.
The biggest difference between data networks and “virtualised SCSI” is in the glass(!) – fibre channel works in a “multi-mode” – many frequencies of light are launched down the same glass fibre cable which will maintain data rates below 10 gbits per second over several hundred metres. Single mode fibre, which has longer been used for more traditional data applications – typically TCP/IP – uses a single colour laser and so the glass can be optimised for that “mode”. Data rates of fifty gigabits per second are achievable over tens of kilometres without amplification. These details are given but after that there are a few other considerations that make the difference between a working installation and a truly flexible/scalable one.
When you buy some fibre-channel storage the manufacturer will ship you patch cords that are commonly refered to as “tight-buffered” cable.

The glass fibres are lined in a nylon jacket which is coated in a plastic sheath. These cables are cheap to manufacture and are flexible enough for dressing within equipment bays. The problem with tight-buffered cable comes when you try and run long lengths of it through voids and dry-risers (between the machine room and the edit suite, for example) – it isn’t really man enough for the job and will often fail. Traditional cable-working techniques tend to compromise it, which is expensive if you have to hire wiring staff or worse still if you lose the edit because the cable has just given up the ghost during that important job. The attraction to most in-house engineering departments is that you can buy the cables ready-made and so you don’t have to concern yourself with manufacturing leads that you have little familiarity with.

By far the better way of providing a fibre infrastructure is to run in a “loose buffered” cable. The construction of this differs in that the fibres float in a mineral oil that is contained within a plastic hose. This is wound in a Kevlar mesh (the same material they make bullet-proof vests out of!) which is all covered in a plastic sheath. The cable scores over tight-buffered cable, in that the fibres can slide within the oil as the cable is pulled around bends and the Kevlar means you can step on the cable and abuse it a lot more than patch cord cable. The bulk of the cost of the cable is in the protective construction and not in the glass fibres themselves and so it becomes very economical to run in a four-core where you might only need two (a transmit-receive pair) or a twenty-four core where you only need eight (for example) – this price scalability means you can future proof yourself (you always end up building more edit suites!) and guard against possible damage (despite the glowing account above it does occasionally get damaged). Neither of these advantages can be ascribed to tight-buffered cable. Although the initial installation cost is marginally higher the total cost of ownership and reliability/flexibility is an order of magnitude better.
Root6 has invested in both training and the necessary equipment to offer a full fibre installation service and will be happy to advise when you are thinking of investing in a SAN. As an aside, in the eighteen months since we opened the fibre division we have not had to return to a client’s premises to repair a broken fibre – we have had to help out several other clients who’ve found that half of the pre-made tight-buffered cables they’ve had run in have failed very quickly.

Labels: , ,

Wednesday, January 11, 2006

NET-IOM board (continued)

As mentioned earlier this week I have been hugely impressed with this network remote control card and have spent the last couple of days thinking about applications for our customers.

Setup is very easy - 12v DC and a network connection. I also got the prototyping kit which has a relay board and a bunch of LEDs you can test with - CPC have them on special at the moment (see here).
Initial thoughts are that is really seems to do what it said it would - I'll have to get another to test the VTR control (as I'm still not sure you can reduce the latency enough - if you're having to packetise a serial stream that should be co-incident with a video reference and them pass it over a TCP network). Anyhow - the webserver side of the board works well and it can ping me an email when events happen. You can see from the screen-shot that the counter is easy to configure as well.
The only area where the documentation is unclear is that the "programming" jumper (J42 on this board) not only allows the board to receive config data over the serial port but it also disables the ethernet connection - makes sense I suppose - that "webserver on a chip" PICT device you can see in the centre probably can't do config changes while serving up over the network - but they should have mentioned that in the documentation.
Another feature that I'm sure has application is that the board will watch a serial stream and when you get to a pre-defined number of characters (1024 bytes is the default) it will stick them into an email and send it to you! Fantastic - I imagine there are many applications where you want to trap an event and see what log data was generated at the time - I have to find applications for this!
For you edification the manual is here.

Labels:


 
Phil's technical blog