Continue reading »]]> So in the latest twist in the long death of Nokia (NOK), there is news from the States and the UK that the suspension of sales of Meego phones (the N9) across these major market places.
This includes the latest N9, now not likely to be seen in the wild in the UK.
So either they’ve got a Windows 7 mobile phone available to drop soon, and they’re clearing the decks ready for this, or they’re not ready to deal with the cost of manufacturing, distribution and restocking when the new phones are ready to go. If the cost of this is so high that they’d cancel the few months of sales of one premium phone platform, then they’re in worse shape than people think. Given the http://www.theglobeandmail.com/globe-investor/nokia-warns-of-weaker-sales-shares-plummet/article2041001/, and poor sales figures released on July 21st, it’s entirely probable.

Continue reading »]]> This weekend has seen a few opportunities for various organisations to do better with their internet service performance.

This is Saturday afternoon, the wife was wanting to get further information on the Queen’s club tennis matches that she was watching on television. An attempt the visit their site resulted in an 503 HTTP error message. This was a nicely formatted standard Drupal error message pane, and advised to try reconnecting later. This occurred shortly after the BBC announced on their coverage that the final on Sunday was being moved from 2:30pm to 12:00pm to avoid the rain that is forecast. (Tennis and rain in Britain are constant enemies during the summer months here)

I’m a fan of the Le Mans 24 hour race, so was wanting to catch up with the start of the race, I visited the website www.lemanslive.com (owned by Michelin, one of the primary sponsors) to obtain the live text information, However at 2:00pm GMT, the site crashed. Since this happens to be at 3:00pm CET, the start of the race, it’s quite obvious that this is due to overloading.

In the end, I switched to using the updates provided by the ACO on twitter via @24hoursoflemans

The site at the moment appears to be redirecting to thier facebook page, (although it wasn’t doing this until eariler on Sunday morning) so again this is an indication that by hosting things in the cloud, they were quickly able to provide the scaling requirements needed to handle the large number of users that can flood in, without having to deploy thier own infrastructure, which did not appear to be suited to the task at hand.

Given the changes and the links that were previously setup prior to the LeMans weekend, this obviously has cost them several opportunties to place product information in front of potential customers during the course of the weekend. Without the opportunity for placement, and for the poor experience delivered, this can seriously harm brand value and customer perception. All of these are opportunites missed.

Oh, and congratulations to Audi for winning, and I’m thankful that the crashes didn’t lead to any severe injuries.

Continue reading »]]> In this Reuters report, it appears that Nokia is still on the downward spiral.

The most worrying thing is that S&P have downgraded (from BBB+) to BBB- thier view of the Nokia (NOK) stock. This means that the following the companies recent announcement that earnings are likely to be substantially lower, the markets don’t appear to believe that Nokia can be turned around.

The main driver appears to be that the high-end phone buyers are not comfortable with Symbian’s current status, and the move to adopt Windows Phone is still aways off, with none of thier current phones running the operating system. There are however, desperately trying to attact those with deeper pockets to thier phones, with a big advertising campaign underway showing that smartphones are really useful. The trouble is, I personally don’t think it’s working for them specifically, and is more likely attracting non-smartphone users into the smartphone fold, but not necessarily specifically to Nokia.

And to cap it all, thier current CTO, Richard Green is on long-term leave, with rumours of a split over the selection of Windows Phone over the Meego platform (the Nokia and Intel mobile Linux platform, born from Maemo and Moblin). As always it’s the content and useability of the platform that matters.. and at the moment neither is able to deliver for Nokia, so we have great hardware, supported by an ancient operating system (Symbian came from the old Psion EPOC operating system, and supported the ARM chipset which Nokia first started to use in the 9210 Communicator), a market with a few applications.. not a good place to start from.

I don’t think this is going to end well, either, and whilst Nokia has in the past made some big changes (most notably moving from rubber goods and cables into telecommunications. I’m not so sure that the current leaders have the opportunity to move the company forward with it’s turn-around, or to make the switch into something different (even more difficult since it no longer has any of the subsiduaries that previously allowed such a move). So perhaps one of the market leading brands (in both volume and technology) will be consigned to the wasteheap of history..

Continue reading »]]> It’s time to change my mobile phone again. I don’t have anything against my Nokia E75, which lasted well.. but the choices I made back in this post ( “Not a camera phone, but a business phone” ) have changed a little.

The Symbain platform hasn’t taken off, and with the Symbian Foundation’s absorbtion back into the Nokia fold, I don’t hold out much hope of this actually being anything more than a domant platform.

So it’s time to look at a new platform, and I’m not a big fan of Apple, it being a fairly closed development environment, so am looking at Android. Android has substantialy developed, especially with a large amount of FroYo (Android 2.2) phones now available, performance and battery life is quite good.

I’m also looking at the HTC Desire HD, as this seems a good platform at the moment. I know that as soon as I make the decision, there are going to be several dual-core phones out there, but you can’t wait forever.. (otherwise there might be rumors of a quad ARM core device, which would be insane..)

The other reason for going with HTC (2498.TW) is that although the device is currently Android 2.2 (FroYo), there’s a rumored upgrade to 2.3 (Gingerbread) in the works. Also HTC don’t lock down thier boot roms, so there’s a good community of developers for the platform on xda-developers.com.

Continue reading »]]> So investigating some issues for the inks company today, I come across a problem that we’ve seen before with Junipers..

A site has problems transferring data across the network between two Junipers, since we’ve been through the mill already for this application, there is a special exclusion application definition for this. So we try the usual trick, which is disable the NSC (disk-based) compression and TCP acceleration by sticking the failing server in the exclusion application. Re-run the transfer, and the problem still exists..

Since we’ve done this, we’ve added several other Juniper sites to the network, along with several hundred users. This means that the pair of servers involved are facing some increased loads from the other functions carried by the server. (The application comes in three parts, one that gathers the data, one that processes it, and the third that supplies that information out to the rest of the organisation. The issues that we have seen so far have all been related to the gathering of the information, since that is the process that generates and logs errors, and is also noticed in missing information if it fails).

The issue is not in the problem of the gathering of the data, but in the probable undersizing of the system(s) that runs the entire application. The problem appears that the system has a finite amount of network buffer space to send or receive the data via the network. If the acceleration for the entire system (both the gathering and publishing sides) is enabled, then we have an issue in which the transfers hit several points of TCP zero window on the gathering side (which was being measured today). This means that the server is running out of space in the system (it normally signifies a bottleneck within the system that prevents the received data being processed effectively). This is not surprising, since the process contacts remote databases, and drags information from them into a consolidated central store (data warehouse). The zero window can also mean that the system at the operating system level is unable to accept more data since the buffer space is exhausted.

By adding the gathering connections into an application definition that precludes the TCP application function, the volume of data being received is throttled (since the TCP window now comes into play for the particular server we’ve got an issue with, since it is South Africa, and the data warehouse is in Arizona, USA). This has in the past restored function for the gathering function, but in the intervening time we’ve added several more users that are using Junipers to connect to the publishing side of the application, and this has increased the load on the total system buffers, since more are now occupied with data leaving the system on it’s way towards it’s subscribers. In the end, disabling TCP acceleration for both sides (gathering and publishing) of the application reduced the loading on the server, and enabled the system to complete both tasks without errors.

I’m fairly convinced that an analysis of this server will show that it is highly overloaded, and that a good dose of memory and some careful operating system tuning of the network stack will enable the TCP acceleration to be enabled again. (Part of this comes from a comment that the processing of the data can take “quite a long time, nearly an hour a site”, when it’s only 10Mb of data that are transferred across the network itself.

So if you’ve got issues with TCP acceleration, and it affects a single server, then it might be an idea to ensure that it’s operating correctly. Check the application loading levels, the level of swap file in use, and the amount of memory that is being reserved for network buffers. It’s not true that you can simply enable TCP acceleration without an impact in the network. You are automatically making each connection work harder, and this will take more resources in the system to support, especially if the system load remains constant.

So there is impact on servers under TCP acceleration, and it ain’t necessarily all good. Make sure your system can cope with the extra network buffer utilisation needed.

Continue reading »]]> It transpires that the issue with IGMP snooping needing to be disabled on certain switches is due to the partial implementation of the multicast IP support within the Juniper WXOS software.

For switches that have IGMP snooping feature, this normally enabled on these switches, and most support IGMP v2. This requires both the multicast end device to advise that the multicast group has been joined, but also that the multicast router to query the end device periodically to determine if the device is still actively part of that group.

IGMP snooping on the switch monitors these messages and enables or disables the forwarding of multicast packets to the particular port that responds, and closes off the port if no membership report information is returned to the router. Because the Juniper does not support IGMP v2, these switches will withdraw the multicast forwarding for the Juniper WXC port as it’s not part of the multicast group that the switch recognises via IGMPv2.

Disabling the IGMP snooping prevents the shutdown of the multicast traffic to non-member ports, and instead floods the multicast traffic to all ports, similar to broadcast traffic processing. As this traffic is now forwarded to the Juniper (and incidentally to all other devices connected to the switch), the WCCP relationship between the Juniper and the routers is maintained. Correct operation of this feature can be seen using the show packet-interception command. This will show the HereIAm and ISeeYou WCCP messages (HereIAm is issued by the Juniper, ISeeYou comes from the routers). Both should be increasing, if the IGMP issue occurs, what is shown is the HereIAm messages continue to be emitted, but the returned ISeeYou messages are prevented from reaching the Juniper via the switch, and this counter stops.

Time for a feature request, methinks..

Continue reading »]]> The large legal organization has had some issues recently.. for some reason the PolicyCentre for their Packetshaper environment has stopped responding (it can be ping’d across the network, but no response to the management traffic). Reset this, and everything springs back into life..

Everything, that is, except a handful of Packetshapers that are refusing to correctly login to the PolicyCentre.

Tried the old trick of the following from the command-line, but no dice, still get just the single read connection to the database, rather than both the read and write connections (which signify a working link)
ds offline
ds online
ds session

So we try the more complex way, which is to disconnect the device from the PolicyCentre and reconnect it, using the following.
ds offline
config unset
config set W.X.Y.Z password convert
ds session

This works, but we then have to juggle the device back into the proper place on the configuration tree. In the intervening time, some of the traffic (most notably their Blackberry push email) has hung up and has a large back log. If we get the information to classify this, we can then sort out the priority that this has against the rest of their traffic. Now back to the usual task of examining the root cause of the issue.

Continue reading »]]> So the consultant from the Inks company phoned again, and needs a little help. Seems that the HP JetDirect printing to some of their sites has broken, since the transition to the new network.
A bit of a look, and some disabling and re-enabling some functions later, and we get back to everything working for a site connected via an IPSec VPN link, with no overall changes.. but now it works.

For the other site, we have an issue that might have been a TCP MSS size problem (connections starts, but fails to transfer data). Fudged the Juniper WX devices with a lower MSS size for accelerated traffic but no dice. It did appear as if the hard disk was busy, so took the traffic out of NSC (the disk based compression engine), again no dice. Disabled TCP acceleration, and everything’s hunky-dory..

The only part of the network which had Junipers at both ends was the other providers connections between the data centers. I’m still certain that they fudge the MTU on their network, even though the changes to MSS should have worked around this. Still another case to open with JTAC. At least we have full traces and diag files for this one.

Continue reading »]]> I said I would never do this again, but despite my better judgement, I dropped in on a friend last night to fix their computer.
It had problems with accessing facebook, and since I’d dropped them a friend request, and they hadn’t replied, it was in my interest to fix this.
I like simple problems, a quick login to facebook on my account showed a problem with the style sheet not loading properly, and the left-hand menu all being screwed up. A reload of the page later, and no problems, my facebook profile was up, and looking like the huge mess that the applications now seem to make it. Clicking on other friends showed no issues either.
A check with the user, and she said that there was the yellow error shield in the bottom left corner of the page when wanted to accept people as her friends. So I get her to log in, and access the page, no error shield, and she can pop-up the notifications and accept them without issues.
So why is it occurring? Seems that a bad copy of some of the behind the scenes files (CSS, JS, etc) got downloaded, and ‘cos her Internet Explorer had somehow got set NEVER to refresh pages, these had stuck in the system. Tweak the settings to Automatic, save, and hopefully all her woes are fixed (facebook wise at least).