Saturday, August 29, 2015

WMATA Speed Restrictions Slowing Your Commute

What’s up with those slow WMATA trains these days?
Commuters of Metrorail have very likely noticed or heard about trains running slower than they usually do. After the incident earlier in August where a “code black” issue did not immediately result in track being taken out of service for repair as required, WMATA was directed to perform track inspections on every mile of track in the system by Acting General Manager/CEO Jack Requa, which has resulted in trains being slowed down in some problem areas and curves. The agency has been using their Track Geometry Vehicle (TGV) to check the system’s rails for defects, as well as manual inspections while walking the tracks to see if the track is safe.

The first to notice ongoing changes after the incident were - and still are - those on the Red Line. Speed restrictions, where the trains are limited to speeds below what the track is ordinarily rated for, were placed on sections of track near the core between Union Station and NoMa-Gallaudet on August 19th where all track ties and fasteners of a 1300-foot section of track are being replaced. Additional track work is being done mid-day between NoMa-Gallaudet and Rhode Island Avenue which is possibly related, but at very least causing single-tracking during the mid-day work window. Both of these portions of mid-day work continue through September 19th.

On August 21st, the speed restrictions were expanded system-wide to any curved section of track rated for running trains at-or-above 35 miles per hour on all lines. WMATA says it is “conducting an aggressive campaign to visually inspect curved sections of track on the Metrorail system” which is why the restrictions were added, however no other information has been publicly released about the issues. In a tweet from WMATA’s Board member Augustine, there are no lingering code black issues known throughout the system.

Wednesday, August 12, 2015

Post-Derailment Reactions

This post will serve as a collection of politicians' responses to today's revelation that last Thursday's train derailment (zero injuries) should have been prevented a month earlier, and shows a significant lack of safety management. WAMU has more. Use this as a reminder to keep those who run/manage/oversee the organization responsible for their actions and those that affect the safety of all WMATA customers, riders, and employees.

WMATA Board of Directors
Mark Warner

Tim Kaine

Sunday, August 9, 2015

Decrease in (Reported) WMATA Track Delays Since 2009

In a conversation on Twitter, this simple question was tweeted at me:

With data from the Daily Service Reports, this shouldn't be too hard to find. Just count up and graph the number of delays categorized under track problems, right? Well, that's exactly what I plan to do with this write-up. If you don't feel like reading everything including the details, I guess you can skip to the bottom and read the conclusion.


The current push for overhauling the older parts of the WMATA Metrorail system is a plan known as Metro Forward:
The Metro Forward improvement program is an ambitious 6-year action plan that is designed to make your life better by making your commuting experience more reliable, more comfortable and more enjoyable.
We are working to provide you with new rail cars, new buses, new tracks, new technology and the rebuilding of essential infrastructure. Just over the coming year we will be rehabilitating and replacing nearly 50 escalators; renovating 12 Metrorail stations; retrofitting track and replacing track circuitry; rehabilitating third rail, running rail and track pads; installing track turnouts; purchasing new police radios; rehabilitating three bus garages; replacing 100 Metrobuses and rehabilitating 100 more. (
At a cost of $5.5 billion, the program started in 2011 is advertised to be replacing significant amounts of track, circuitry, escalators, and more. Focusing primarily on track for this article, Metro Forward is responsible for replacing on average 31,000 track fasteners and 18,000 ties per year, reducing the number of welds in the track, and completely replacing over 60 miles of track over the program's duration in addition to what is replaced during regular maintenance. (

Through October of 2014, WMATA shows that they have made some fairly significant progress in the program. Noted in the graphs below, Metrorail is working out of a backlog due to previous underinvestment in the rail system. One of the main items that is still unresolved and won't be for a few years is decreasing the number of track joints. Two joints are created each time a new piece of rail is inserted into the system - one at each end of the new piece - which end up causing a bumper ride for customers, and decreasing the lifespan of train wheels and the track itself. During maintenance windows, teams go around joining or welding these to the rail on either side in order to create one continuous piece of rail for trains to run on.

Number of Canceled (Did Not Operate) Trains on the Rise

This article has been cross-post to the FixWMATA website as well. Check it out!

Does it sometimes feel like more and more WMATA trains don’t run as they’re scheduled to? I’m here to say, unfortunately, it is not your imagination or made up. Ever since the start of revenue service on the Silver Line, the number of train cancellations – those that do not operate as scheduled – have gone up and up. Formerly averaging 37 trains per month that did not operate in the 5 years before the Silver Line’s opening, the number of canceled trains has now spiked to 141 canceled trains on average per month since July 2014 through July 2015. This impacts the system most when the maximum number of trains are needed for service, that is, morning and evening rush hours.
The 6am hour is usually the one most impacted, closely followed by the 7am, 3pm, and 4pm hours (24, 29, 24, and 17 trains canceled on average per month for each hour, respectively). These four hours are some that WMATA says are the most important to them as a transit agency.
When broken down by line, it is plainly obvious to see that the Orange line is most impacted by the opening of the Silver line, and in general, all cancelled trains since 2012. Surprisingly though, the Green and (to a lesser-extent) Yellow lines have also been impacted in recent months, neither of which share track with the Silver line and are unlikely to share rail yards. Again, the spike in scheduled-but-cancelled trains is clear to see starting once the Silver line went into revenue service in July of 2014.

All told, this issue is not just of importance to riders, but also one of importance to WMATA. If the number of trains canceled correlates at all to the number of customers who choose alternate methods of transportation, this looks to parallel decreases in ridership and lower revenue for the system. Each 6-car train cancelled loaded with 100 passengers per train is potentially an extra 600 riders in the system, meaning the average rise in cancellations post-Silver Line could be resulting in around 750,000* fewer fare-generating trips per year riding the system.

Thus in addition to bringing customers more frustration by increasing crowding, waits, or resorts to alternate transportation methods, WMATA may end up overestimating the revenue brought in by rail operations of a tune of $1.5 million or more.

* Each month has seen an average increase of 104 extra cancelled trains as compared to before the Silver line. If we assume each of these is a 6-car train with each car carrying on average 100 passengers, this adds up to 748,800 cancelled “seats” moving through the system.
$ Data for March 2011 through April 2012 is missing. February 2011 data only constitutes the first half of the month.

# Raw data can be provided upon request.

Tuesday, July 14, 2015

The Silver Line is Open: What About Performance?

Correction: The Rail On-Time Performance chart has been updated with one that includes the Blue Line. I apologize to all BL riders that I left off. Thanks to @keck41 for alerting me.

With the WMATA Metrorail Silver Line Phase I now open, the overall system appears to still be functioning but is hobbling along more now than ever. In customers eyes delays have increased, breakdowns and single-tracking are more frequent, and crowding has grown. The recent WMATA proposal to optimize the rail system calls for cutting trains on the Orange, Silver, Yellow, and Green lines while Blue line service capacity would be increased. In order to attempt to optimize trains running through the Rosslyn tunnels - each with a theoretical maximum of 26 trains per hour - WMATA wants to reduce the total number of trains running through from 26 to around 23 trains per hour, and increase the percentage of 8-car trains being run on the lines. One of WMATA's lines of reasoning for this change is train spacing:
“All those trains really have to hit that tunnel almost perfectly timed. If one thing goes off, it can throw off the entire system,” said [Sherry] Ly. Running fewer trains would improve reliability, she said. The proportion of eight-car trains on the affected lines also would increase (most rush hour trains currently carry only six railcars).
Is this the proper question that needs to be solved, however, and really why Metro is making this change? The ultimate reason, more likely, is that Metro badly needs to reduce the number of train cars in service in order to increase performance again. Here's why:

Rail Line Performance

WMATA Rail Line On-Time Performance, 2009-2015
To get an idea of the overall picture, this graph shows the WMATA on-time performance for all rail lines dating back to mid-2009. Visible starting July 2014 is the addition of the Silver line with an average on-time performance through March of 86.5% - the lowest average on-time performance of all 6 rail lines between opening July 2014 and March 2015.The introduction of this new line correlates incredibly well with significant decreases in performance of the Orange and Green lines, and less so for the Red and Yellow lines. For the most part through the entire chart, all lines are reasonably close in performance numbers relative to each other.

Rail Equipment

To take a look at another part of the equation, have you ever wondered about the reliability of the rail cars that Metro runs? Not all of them have the best history. While they are the oldest, the 1000 series actually does not have the worst mean distance between delay (MDBD) measurement (granted, they have other critical issues). At an average distance of 30,788mi, the 4000-series cars are the least reliable in the WMATA fleet*. This is only all too clear on the graph below. The second worst-performing series in the fleet are the 1000s, closely followed by the 5000s at 50,028 an 51,456mi respectively. Given the data available, there does not appear to be a statistically-significant correlation between the Silver line opening and rail car performance itself. There is potentially a decrease in performance of the 6000-series cars after the Silver line opening, but there isn't enough data yet to know if that's a temporarily blip or a new long-term trend.
WMATA Rail Car Mean Distance Between Delays (by Series) - 2009 - 2015

WMATA Rail Car Series Mean Distance Between Delays, Oct/2013-Mar/2015

Friday, July 3, 2015

Washington Metrorail Q2 CY2015 Daily Status Report Overview

[updated] This post has been updated on 4 July 2015 to reflect the location of stations where trains did not operate as scheduled.
The Washington Metropolitan Area Transit Authority (Metro) was created by an interstate compact in 1967 to plan, develop, build, finance, and operate a balanced regional transportation system in the national capital area. Metro began building its rail system in 1969, acquired four regional bus systems in 1973, and began operating the first phase of Metrorail in 1976. Today, Metrorail serves 91 stations and has 117 miles of track. Metrobus serves the nation's capital 24 hours a day, seven days a week with 1,500 buses. Metrorail and Metrobus serve a population of 5 million within a 1,500-square mile jurisdiction. Metro began its paratransit service, MetroAccess, in 1994; it provides about 2.3 million trips per year.
The Washington Metropolitan Area Transit Authority (WMATA) operates a significant number of trains on hits network every day, and accrues delays and other operational issues over time. WMATA creates a log of all of these delays - the Daily Service Report (DSR) - that affect their trains and cause passenger delays of three minutes or more at a stop. Raw data used for this and other analyses can be found on the WMATA website at:

This post sets out to take the three months of data from April to June 2015 (Q2 CY2015) and point out trends and other data of interest, especially changes in delay rates over time, delay types, and how these have affected each of the system's six rail lines during the time period of interest.

Due to the nature of the DSR document, the fact that anything is contained within it means that it had a negative impact on train and/or passenger operations. Each entry in the DSR notes the time of the delay, the line and station, and the cause. Most entries include the delay length, but a percentage of reports do not include this data. For this and all data that does not include an estimate, the delay length has been left blank. This has the possible consequence of not including significant or other delays in the data matrix, however it is not reasonable to fill in the data as this would induce error and potentially-incorrect information.

Data Comments
Due to the format of some data, the classification of delay has been changed in certain circumstances:
  • When an incident occurred at a station served by multiple lines, the incident was classified under the line that caused the delay. For instance, if an Orange line train was offloaded due to brake problems at Ballston (affecting the Silver line as well), the incident was classified under the Orange line heading
  • Instances of "passenger struck by the train" have been reclassified as a Medical Emergency
  • "Track obstruction" has been classified under Track Problem
  • "Tresspassers" and "unauthorized persons on the track" have been classified under Police Activity
  • Escalator outages causing station trains to skip stations and induce delays have been classified as Operational Problem
  • Trains that are noted as "expressed" (meaning they it did not service a particular station or stations) do not have a delay in minutes associated with them, as none is provided by WMATA. There is certainly a delay associated with a train skipping a stop, however it would not be proper to assign a delay to these without further study.
  • Total delay, April 2015: 572 delays, or 3763 minutes
  • Total delay, May 2015: 520 delays, or 3519 minutes
  • Total delay, June 2015: 698 delays, or 4709 minutes
  • Total delay, 2Q CY2015: 1790 delays, or 11191 minutes (avg 7 min/delay)
The top five causes of Metrorail train delays caused a total of 9048 minutes of delay throughout the system, or 81% of the total delayed time. The graph below shows the breakdown of the top five types of delay over each of the three months as measured by total minutes of delay.
WMATA Monthly Total Minutes by Type of the Top 5 Causes of Delay for Q2CY15

  • Track problems caused 831 minutes of delay (13 minutes per delay on average)
  • Door problems caused a total of 1352 minutes of delay (8 minutes per delay on average)
  • Operational problems caused 1020 minutes of delay (7 minutes per delay on average)
  • Trains that did not operate caused 3146 minutes of delay (6 minutes per delay on average)
  • Brakes problems caused 2699 minutes of delay (6 minutes per delay on average)

Most Frequent Cause of Delay
The most frequent causes of delay during the second quarter of 2015 were trains that did not operate as scheduled. This can happen if the rail cars to run the scheduled train are unavailable, if there is no operator, or for other unspecified reasons. For instance, one example is "a Franconia-Springfield-bound Blue Line train at Largo Town Center did not operate, resulting in a 12-minute gap in service." (6/15/2015). Each train that did not operate caused a service gap of approximately 6 minutes on average.

The graph below shows the time of day for each of the three months in the quarter when there were trains that did not operate as scheduled. The number of trains that did not operate rose overall from 124 in April to 128 in May, and then increased to 223 in June. The increase in this type of delay event can likely be partially attributed to all 100 4000-series train cars being pulled from revenue service during the quarter ( over issues with doors opening while moving. Without the 100 4000-series cars to run on the rail system WMATA would have to also decrease the number of 1000-series rail cars in service, since those are not allowed to be either the head-end or rear pair of cars on any train consist. 50 of the 4000-series rail cars have been put back into service as of this writing in early July.

WMATA Monthly Totals of Trains that "Did Not Operate" per Hour (0hr-23hr) for Q2 CY15
Diving into the data a little, we cane take a look to see which stations are affected by these trains marked "Did Not Operate." The majority of the increase in these trains is centralized on three stations throughout the system - one on Orange, and two on Green: Vienna, Greenbelt, and Branch Avenue. All three of these stations are termini, and are where the vast majority of Metrorail trains will originate on their trips. For the quarter, these three stations account for 48% of all trains that did not operate.
WMATA Trains Per Station Classified "Did Not Operate" for Q2CY15. Grouped by Metrorail line color.

The second most-frequent cause of train delay is those that have been expressed past a station. This terminology means that the train does not stop, and instead continues on to the next station on its route. This is usually performed by WMATA "for schedule adherence/improved train spacing" on the line, especially during recovery from an earlier incident causing train bunching.

WMATA Service Delays by Type per Month for Q2 CY15
Most Delayed Line
For all three months in the quarter, the Red line "won" with the most number of delays for a total of 516 over the quarter. Note also that the Red line is the single longest in the system, and thus proportionally it would be expected to have more delays than the rest.
WMATA Service Delays by Line for Q2 CY15

Least Delayed Line
The least-delayed line throughout the Metro system during Q2 of 2015 is the Blue Line, with 165 total delays. In addition to having higher headways (thus, fewer trains) than other lines in Metrorail system, the significant portion of the Blue line route is shared with others (Yellow, Silver, and Orange) which all have higher number of delays which could potentially impact Blue line performance as well.

Longest Delay
There were multiple delays (five) that tied for the longest delay/impact to customers of up to 60 minutes. The first noted delay during the second quarter occurred on Friday April 3rd, 2015 at 8:02am:
A Glenmont-bound Red Line train outside Cleveland Park experienced a brake problem. A Glenmont-bound Red Line train was used to recover the incident train. Both trains were moved to the platform and offloaded. Several trains were single tracked around the incident train and several trains were offloaded and turned back for schedule adherence/improved train spacing. Passengers experienced delays up to 60 minutes.
 Of the same length was another delay on Thursday April 16th, beginning at 9:39am:
A Greenbelt-bound Yellow Line train at Fort Totten reported a track problem. Green Line service was suspended between Prince Georges Plaza and Georgia Avenue until approximately 10:30 a.m. Several trains were offloaded and turned back for schedule adherence/improved train spacing. Passengers experienced delays up to 60 minutes.
The next delay of 60 minutes was not until a month later on Thursday May 21st at 3:36pm:
Orange/Silver/Blue line train service was suspended between Eastern Market & Minnesota Ave and Eastern Market & Benning Road due to a power problem. Shuttle bus service was provided. Power was restored at approximately 4:50 p.m. Passengers experienced delays up to 60 minutes. 
Monday, June 1st brought the next 60-minute delay at 7:21pm:
A Glenmont-bound Red Line train at Shady Grove was delayed due to a signal problem. Passengers experienced delays up to 60 minutes.
 Rounding out the quarter, a 60-minute delay was reported on Monday, June 29th beginning at 5:34pm:
A Shady Grove-bound Red Line train outside Farragut North experienced a brake problem. A Grosvenor-Strathmore-bound Red Line train at Metro Center was offloaded and used to recover the incident train, which was moved to the platform and offloaded. Several trains were single tracked around the incident train and several trains were offloaded and turned back for schedule adherence/improved train spacing. Passengers experienced delays up to 60 minutes.
While the link to the raw WMATA DSR data is provided above, the processed and analyzed dataset is not included. This can be provided upon request by contacting me @srepetsk on Twitter or at blog [at] srepetsk [dot] net via email.

While I have done my best to ensure the accuracy of the data contained in this post, it is provided as-is with no guarantee that it is correct. Please feel free to contact me you note an error, or suspect there may be an error.

The author of this content does not speak for and is in no way associated with the Washington Metropolitan Area Transit Authority other than being a rider of the system.

Sunday, March 1, 2015

Review: Pockethernet, "The Swiss army knife of network administrators"

Being a systems & network administrator, sometimes I get to deal with making, crimping, repairing, or otherwise generally troubleshooting cables, switches, and basic networking functions. Generally one might use a Fluke or other network tester in a situation where you might need to test any of the above - for example, a user calls in and says they need a long Ethernet cable made and you don't have any non-bulk cable handy. Unless you do this a lot, a Fluke isn't something that you're going to just have sitting around and so you might try visually looking at a cable or plugging it in to network hardware you have laying around to see if the cable works. This process can be cumbersome, inefficient, and take far more time than it otherwise should.

Well, not anymore. The Pockethernet, a network testing device stemming from an Indiegogo funding campaign early in 2014, is attempting to change all of that. Brought to life by German duo Zoltan Devai and Jeroen van Boxtel, the device is aiming to be an all-in-one device to make every IT person's life easier. I received mine in the mail a few days ago and have been playing with it to develop some first impressions since then. Past the video, I get into the unpacking and the Pockethernet's uses!

The original Indiegogo campaign closed in March of 2014 with 370% of the original $50,000 goal, and there have been several delays since the devices were supposed to have been shipped. This is not the end of the world, and I only had thoughts that I might not get the device a couple of times. There have been over 20 updates sent out to backers between the campaign closing and now, keeping us up-to-date with the status of production, shipping and several challenges that were encountered along the way. Producing the devices took longer than expected with a couple revisions and retooling required, regulations taking longer than expected to be sorted out for all the governing bodies worldwide, and even running into difficulties dealing with UPS/DHL.

All of that is now nearing completion, and devices have been and are being shipped. After being unpacked, this is the case that the unit and cables came in.
Pockethernet in case
In addition to the case above, two documents were included: a welcome document, and a manual about the device itself. The first page of the information document is dedicated to regulatory information (legally-required text, yadda yadda yadda). and the rest of it talks about the device itself.
Pockethernet case opened
The Pockethernet comes with a dual-function dongle so that you can either test to find the wire map of a cable or turn what you have into a loopback cable, an Ethernet cable, and a short USB cable for charging.
Front of Pockethernet 
The device itself is contained in a machined metal case, and feels incredibly sturdy. The front and back of the device are closed with clear plastic so that you can see through to the other side. The PCB is the main component inside the case, and the 750mAh battery is situated just on top of it.
On this front side are the Ethernet jack itself and 5 LEDs:
Pockethernet - Front
Pockethernet - Rear
Rear of Pockethernet
It appears that the logo and regulatory information printed onto the outside of the case is reversed from where it sound be. When seated so that the Pockethernet name and logo are visible as such in the photos above, the PCB is seated near the top of the case with battery hanging below it. When flipped to match the documents in the manual, the regulation information is right-side up - and who wants to see that?
Wiremap/Loopback dongle
This little dongle comes with the Pockethernet; there is not yet any documentation to go along with it, so the "Loopback" and "Wiremap" labels on it are all there is to go on. Those are fairly self-explanatory, however.
Pockethernet start screen
When starting up the Pockethernet Android application this is the first and main screen that appears. Down the left column are icons for the 4 cable pairs, Power over Ethernet, link, and DHCP/network information. Selecting Connect at the bottom of the screen starts the connection between the phone and the Pockethernet. To do a regular cable test on a disconnected Ethernet cable, the Wiremap portion of the dongle lets you test to make sure that the cable generally works.
Wiremap test function
Once connected to the cable that you want to measure or test, selecting the Refresh button at the bottom is what gets the test to actually run. The screen above shows the cables and the which pins are connected where. This test took place with a regular straight-through Ethernet cable, so the wiremap function served to simply reflect the signal back to the Pockethernet from the opposite end. Per the backer forums, the O S and C listed next to each pair appear to stand for Open, Shielded, and Closed in relation to the electric circuits.
Wiremap TDR results
Time-Domain Reflectometry (TDR) is used to find the length of the cable that you have connected. In this case, I tested with a 2-meter cable. The reporting is wonky and shows different lengths for the pairs, which is a known issue. After a few weeks, the developers hope to release an updated version of the application with fixes for bugs reported in that timeframe. Given this, the results appear to properly show that the cable is not "connected" to another device (Wiremap function, not Loopback) but is returning results.
Cable gigabit information
This screen isn't the most helpful, but it appears to show that all four pairs of cables are connected and which is the transmit or receiving side.
Online network test
One of the neat features of the device is that you can do an Online test with it, meaning you can make it connect to your network, receive a static or DHCP address, and ping up to three addresses. A quirk of the device appears to be that you have to run a test on the cable first before you are able to run the Online test. Each test to verify connectivity with the server(s) that you specify takes approximately 3 seconds so you can get enough information to know what is working and what might not be.
Offline network testing
If you have a cable toner, the top half of the Offline testing screen is useful to you. Like any other tone test, you can try to use this to find a cable that you're looking for in a patch panel or other scenario when otherwise finding it would be difficult. The bottom half lets you test the Bit Error Rate (BER) of a cable using the Loopback side of the dongle. Testing at 1000Mbps is currently broken (another known issue) but 10/100Mbps works just fine.
Generate report screen
A neat feature built into the software is that you can send a PDF of the latest test result that you have generated to an email address in order to export some data. It piggybacks off of whatever mail program you have set up on your phone, but it gets the job done. The report itself is basic and includes all the information shown above minus the graphics, so it isn't incredibly useful yet. Styling and image work will go a long way to make the report feature more useful. Yes, that is a button in the bottom-right that lets you attach a photo to the generated report, perhaps of the drop that you are testing on or other verification of the job you've just completed.
Generated PDF of test results
The report, while nifty, isn't incredibly useful yet. The wiremap and TDR information, as shown above, appears to be inaccurate/incorrect displaying Short/Open when Closed would be the proper information to have been included and a > 0m length result. Again, this is a software bug that can and hopefully will be be fixed with an app update.
Finally, the software has a couple basic options that you can change as well as lets you see the device and software information. There isn't all that much here yet, but I expect more to come in future software updates.

While playing with the device for a short while I discovered and read about a few odd things it does, some of which can be worked around.
  • There isn't yet a quickstart or how-to guide for using the product, although there is an active backer forum where questions are being answered very quickly. If you generally know something about networking and what you are doing, then it probably will not take you long to get up to speed and make use of the device.
  • The Pockethernet cannot be used while connected to its USB charger.
  • Before you can start an Online test, you are required to run a generic cable test, presumably to let the software know that it's connected to something.
  • The cable length results are sometimes correct, but not in other cases. This is a known issue which should be fixed shortly.
  • Testing the BER at gigabit speeds currently does not work, although it does at 10 and 100Mbps. As before, this is another known issue reported on the forums.
So...does it really do that?
The device as delivered is a solid piece of hardware that accomplishes many of the goals it set out to accomplish, but the software is not completely there yet. For something that I put money down before there was even a physical product, it holds great promise through continued software updates to fix bugs and add additional functionality. One item specifically mentioned that will be added is LLDP/CDP support, and other features to be added include VLAN support, SNMP/web configuration, and 802.x support.

The Pockethernet is still in its early stages, but looks to only have a bright future ahead with continued software updates. At $150 (not yet generally available for purchase) or even slightly more, it is a steal compared to the larger and more-expensive network tools for basic network testing and will continue to chip away at the higher-end tools as more functionality is added. Having only possessed the device for around a week I have already had to use it several times to verify cables both at home and at work, so it is already paying for itself. If you can steer around the various bugs that exist currently, I would definitely suggest looking to purchase the Pockethernet when it becomes available. Otherwise, wait a few months for those to be ironed out and new features added, and then purchase yourself a Pockethernet. I can certainly see myself never needing another network testing tool as long as I have my Pockethernet by my side.