Post Syndicated from Rohit Kumar original https://www.servethehome.com/broadcom-trident-4-x7-for-400gbe-networking-launched/
The Broadcom Trident 4-X7 is the company’s new enterprise ToR solution for 50GbE and 100GbE to servers with 400GbE uplinks
The post Broadcom Trident 4-X7 for 400GbE Networking Launched appeared first on ServeTheHome.
Post Syndicated from Matt Granger original https://www.youtube.com/watch?v=W6XQN8CwlJY
Post Syndicated from Mingwei Zhang original http://blog.cloudflare.com/radar-routing/
Routing is one of the most critical operations of the Internet. Routing decides how and where the Internet traffic should flow from the source to the destination, and can be categorized into two major types: intra-domain routing and inter-domain routing. Intra-domain routing handles making decisions on how individual packets should be routed among the servers and routers within an organization/network. When traffic reaches the edge of a network, the inter-domain routing kicks in to decide what the next hop is and forward the traffic along to the corresponding networks. Border Gateway Protocol (BGP) is the de facto inter-domain routing protocol used on the Internet.
Today, we are introducing another section on Cloudflare Radar: the Routing page, which focuses on monitoring the BGP messages exchanged to extract and present insights on the IP prefixes, individual networks, countries, and the Internet overall. The new routing data allows users to quickly examine routing status of the Internet, examine secure routing protocol deployment for a country, identify routing anomalies, validate IP block reachability and much more from globally distributed vantage points.
It’s a detailed view of how the Internet itself holds together.
The Internet consists of tens of thousands of interconnected organizations. Each organization manages its own internal networking infrastructure autonomously, and is referred to as an autonomous system (AS). ASes establish connectivity among each other and exchange routing information via BGP messages to form the current Internet.
When we open the Radar Routing page the “Routing Statistics” block provides a quick glance on the sizes and status of an autonomous system (AS), a country, or the Internet overall. The routing statistics component contains the following count information:
We also show the breakdown of these numbers for IPv4 and IPv6 separately, so users may have a better understanding of such information with respect to different IP protocols.
For a given network, we also show the BGP announcements volume chart for the past week as well as other basic information like network name, registration country, estimated user count, and sibling networks.
BGP as a routing protocol suffers from a number of security weaknesses. In the new Routing page we consolidate the BGP route leaks and BGP hijacks detection results in one single place, showing the relevant detected events for any given network or globally.
The BGP Route Leaks table shows the detected BGP route leak events. Each entry in the table contains the information about the related ASes of the leak event, start and end time, as well as other numeric statistics that reflect the scale and impact of the event. The BGP Origin Hijacks table shows the detected potential BGP origin hijacks. Apart from the relevant ASes, time, and impact information, we also show the key evidence that we collected for each event to provide additional context on why and how likely one event being a BGP hijack.
With this release, we introduce another anomaly detection: RPKI Invalid Multiple Origin AS (MOAS) is one type of routing conflict where multiple networks (ASes) originate the same IP prefixes at the same time, which goes against the best practice recommendation. Our system examines the most recent global routing tables and identifies MOASes on the routing tables. With the help of Resource Public Key Infrastructure (RPKI), we can further identify MOAS events that have origins that were proven RPKI invalid, which are less likely to be legitimate cases. Users and operators can quickly identify such anomalies relevant to the networks of interest and take actions accordingly.
The Routing page will be the permanent home for all things BGP and routing data in the future; we will gradually introduce more anomaly detections and improve our pipeline to provide more security insights.
Apart from examining the overall routing statistics and anomalies, we also gather information on the routing assets (IP prefixes for a network and networks for a country) and networks’ connectivity.
Tens of thousands autonomous systems (ASes) connect to each other to form the current Internet. The ASes differ in size and operate in different geolocations. Generally, larger networks are more well-connected and considered “upstream” and smaller networks are less connected and considered “downstream” on the Internet. Below is an example connectivity diagram showing how two smaller networks may connect to each other. AS1 announces its IP prefixes to its upstream providers and propagates upwards until it reaches the large networks AS3 and AS4, and then the route propagates downstream to smaller networks until it reaches AS6.
In the routing page, we examine what IP prefixes any given AS originates, as well as the interconnections among ASes. We show the full list of IP prefixes originated for any given AS, including the breakdown lists by RPKI validation status. We also show the detected connectivity among other ASes categorized into upstream, downstream and peering connections. Users can easily search for any ASes upstream, downstream, or peers.
For a given country, we show the full list of networks registered in the country, sorted by the number of IP prefixes originated from the corresponding networks. This allows users to quickly glance and find networks from any given country. The table is also searchable by network name or AS number.
Like all the other data, the Cloudflare Radar Routing data is powered by our developer API. The data API is freely available under Creative Commons Attribution-NonCommercial 4.0 (CC BY-NC 4.0) license. In the following table, we list all of our data APIs available at launch. As we improve the routing section, we will introduce more APIs in the future.
| API | Type |
|---|---|
| Get BGP origin hijack events | Anomaly detection |
| Get BGP route leak events | Anomaly detection |
| Get MOASes | Anomaly detection |
| Get BGP routing table stats | Routing information |
| Get prefix-to-origin mapping | Routing information |
| Get all ASes registered in a country | Routing information |
| Get AS-level relationship | Routing information |
The Cloudflare Radar prefix-to-origin mapping API returns the matching prefix-origin pairs observed on the global routing tables, allowing users to quickly examine the networks that originate a given prefix or listing all the prefixes a network originates.
In this example, we ask of “which network(s) originated the prefix 1.1.1.0/24?” using the following cURL command:
curl --request GET \
--url "https://api.cloudflare.com/client/v4/radar/bgp/routes/pfx2as?prefix=1.1.1.0/24" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer YOUR_TOKEN"
The returned JSON result shows that Cloudflare (AS13335) originates the prefix 1.1.1.0/24 and it is a RPKI valid origin. It also returns the meta information such as the UTC timestamp of the query as well as when the dataset is last updated (data_time field).
{
"success": true,
"errors": [],
"result": {
"prefix_origins": [
{
"origin": 13335,
"peer_count": 82,
"prefix": "1.1.1.0/24",
"rpki_validation": "Valid"
}
],
"meta": {
"data_time": "2023-07-24T16:00:00",
"query_time": "2023-07-24T18:04:55",
"total_peers": 82
}
}
}
BGPKIT monocle is an open-source command-line application that provides multiple utility functions like searching BGP messages on public archives, network lookup by name, RPKI validation status for a given IP prefix, etc.
By integrating Cloudflare Radar APIs into monocle, users can now quickly lookup routing statistics or prefix-to-origin mapping by running monocle radar stats [QUERY] and monocle radar pfx2as commands.
➜ monocle radar stats
┌─────────────┬─────────┬──────────┬─────────────────┬───────────────┬─────────────────┐
│ scope │ origins │ prefixes │ rpki_valid │ rpki_invalid │ rpki_unknown │
├─────────────┼─────────┼──────────┼─────────────────┼───────────────┼─────────────────┤
│ global │ 81769 │ 1204488 │ 551831 (45.38%) │ 15652 (1.29%) │ 648462 (53.33%) │
├─────────────┼─────────┼──────────┼─────────────────┼───────────────┼─────────────────┤
│ global ipv4 │ 74990 │ 1001973 │ 448170 (44.35%) │ 11879 (1.18%) │ 550540 (54.48%) │
├─────────────┼─────────┼──────────┼─────────────────┼───────────────┼─────────────────┤
│ global ipv6 │ 31971 │ 202515 │ 103661 (50.48%) │ 3773 (1.84%) │ 97922 (47.68%) │
└─────────────┴─────────┴──────────┴─────────────────┴───────────────┴─────────────────┘
➜ monocle radar pfx2as 1.1.1.0/24
┌────────────┬─────────┬───────┬───────────────┐
│ prefix │ origin │ rpki │ visibility │
├────────────┼─────────┼───────┼───────────────┤
│ 1.1.1.0/24 │ as13335 │ valid │ high (98.78%) │
└────────────┴─────────┴───────┴───────────────┘
Visit Cloudflare Radar for additional insights around (Internet disruptions, routing issues, Internet traffic trends, attacks, Internet quality, etc.). Follow us on social media at @CloudflareRadar (Twitter), cloudflare.social/@radar (Mastodon), and radar.cloudflare.com (Bluesky), or contact us via e-mail.
Post Syndicated from David Belson original http://blog.cloudflare.com/q2-2023-internet-disruption-summary/
This post is also available in Deutsch, Français, 日本語, 简体中文, 繁體中文 and 한국어.
Cloudflare operates in more than 300 cities in over 100 countries, where we interconnect with over 12,000 network providers in order to provide a broad range of services to millions of customers. The breadth of both our network and our customer base provides us with a unique perspective on Internet resilience, enabling us to observe the impact of Internet disruptions.
The second quarter of 2023 was a particularly busy one for Internet disruptions, and especially for government-directed Internet shutdowns. During the quarter, we observed many brief disruptions, but also quite a few long-lived ones. In addition to the government-directed Internet shutdowns, we also observed partial or complete outages due to severe weather, cable damage, power outages, general or unspecified technical problems, cyberattacks, military action, and infrastructure maintenance.
As we have noted in the past, this post is intended as a summary overview of observed disruptions, and is not an exhaustive or complete list of issues that have occurred during the quarter.
Late spring often marks the start of a so-called “exam season” in several Middle Eastern and African countries, where students sit for a series of secondary school exams. In an attempt to prevent cheating on these exams, governments in the countries have taken to implementing wide-scale Internet shutdowns covering time periods just before and during the exams. We have covered these shutdowns in the past, including Sudan and Syria in 2021 and Syria, Sudan, and Algeria in 2022. This year, we saw governments in Iraq, Algeria, and Syria taking such actions.
In the weeks prior to the start of this year’s shutdowns, it was reported that the Iraqi Ministry of Communications had announced it had refused a request from the Ministry of Education to impose an Internet shutdown during the exams as part of efforts to prevent cheating. Unfortunately, this refusal was short-lived, with shutdowns ultimately starting two weeks later.
In Iraq, two sets of shutdowns were observed: one impacted networks nationwide, except for the Kurdistan Region, while the other impacted networks within the Kurdistan Region. The former set of shutdowns were related to 9th and 12th grade exams, and were scheduled to occur from June 1 through July 15, between 04:00 and 08:00 local time (01:00 – 05:00 UTC). The graphs below show that during June, shutdowns took place on June 1, 4, 6, 8, 11, 13, 15, 17, 21, 22, 24, 25, and 26, resulting in significant disruptions to Internet connectivity. The shutdowns were implemented across a number of network providers, including AS203214 (HulumTele), AS59588 (Zain), AS199739 (Earthlink), AS203735 (Net Tech), AS51684 (Asiacell), and AS58322 (Halasat). The orange-highlighted areas in the graphs below show traffic on each network provider dropping to zero during the shutdowns.
As noted above, exam-related Internet shutdowns were also implemented in the Kurdistan region of Iraq. One report quoted the Minister of Education of the Kurdistan Regional Government as stating "The Internet will be turned off as needed during exams, but just like in previous years, the period of the Internet shutdown will not be lengthy, but rather short.” To that end, the observed shutdowns generally lasted about two hours, occurring between 06:30 and 08:30 local time (03:30 – 05:30 UTC) on June 3, 6, 10, 13, 17, and 24. The graphs below show the impact across three network providers in the region: AS21277 (Newroz Telecom), AS48492 (IQ Online), and AS59625 (KorekTel).
Additional details about both sets of Internet shutdowns in Iraq can be found in our June 13 blog post: Exam-related Internet shutdowns in Iraq and Algeria put connectivity to the test.
2023 marks the sixth year that Algeria has disrupted Internet connectivity to prevent cheating during nationwide exams. In 2022, we noted that “it appears that the Algerian government has shifted to a content blocking-based approach, instead of a wide-scale Internet shutdown.” It appears that the same approach was taken this year, as we again observed two nominal drops in traffic during each of the exam days, rather than a complete loss of traffic. These traffic shifts were observed on mobile network providers AS33779 (Ooredoo/Wataniya), AS327931 (Djezzy/Optimum), and AS327712 (Mobilis/Telecom Algeria). The first disruption takes place between 08:00 – 12:00 local time (07:00 – 11:00 UTC), with the second occurring between 14:00 – 17:00 local time (13:00 – 16:00 UTC).
After implementing four exam-related Internet shutdowns in 2022, this year saw just two. On June 25 and 26, Internet shutdowns took place between 05:00 – 08:30 local time (02:00 – 05:30 UTC). Syrian Telecom (AS29256), the government-affiliated telecommunications company, informed subscribers in a Facebook post that the Internet would be cut off at the request of the Ministry of Education.
In Senegal, violent protests over the sentencing of opposition leader Ousmane Sonko to jail led the government to restrict access to platforms including WhatsApp, Facebook, Twitter, Instagram, TikTok, Telegram, Signal, and YouTube. On June 4, the Senegal Ministry of Communication issued a statement temporarily suspending mobile Internet access, with a followup statement on June 6 ending the suspension. These disruptions to mobile Internet access were visible on two network providers within the country: AS37196 (Sudatel Senegal) and AS37649 (Tigo/Free).
As shown in the graphs below, the shutdowns on Sudatel Senegal occurred from 15:00 local time on June 3 through 01:00 local time on June 5, and then again from 13:00 local time on June 5 until 01:00 local time on June 6. The three shutdowns seen on Tigo/Free took place between 15:30 – 19:00 local time on June 3, from 13:45 local time on June 4 until 02:05 local time on June 5, and from 13:05 local time on June 5 through 01:00 local time on June 6. (Senegal is UTC+0, so the local times are the same as UTC.)
In Mauritania, authorities cut off mobile Internet services after protests over the death of a young man in police custody. The shutdown began at 23:00 local time on May 30, and lasted six days, with connectivity returning at 23:00 local time on June 6. (Mauritania is UTC+0, so the local times are the same as UTC.) The graphs below show a near complete loss of Internet traffic during that period from AS37541 (Chinguitel) and AS37508 (Mattel), two mobile network providers within the country.
On May 9, Imran Khan, former Prime Minister of Pakistan was arrested on corruption charges. Following the arrest, violent protests erupted in several cities, leading the government of Pakistan to order the shutdown of mobile Internet services, as well as the blocking of several social media platforms. The figures below show the impact of the ordered shutdown to traffic on four mobile network providers within the country: AS24499 (Telenor Pakistan), AS59257 (China Mobile Pak), AS45669 (Mobilink/Jazz), and AS56167 (Ufone/PTML). The ordered shutdown caused a complete loss of Internet traffic from these networks that started at 22:00 local time (17:00 UTC) on May 9 at Telenor and China Mobile Pakistan, 18:00 local time (13:00 UTC) on Mobilink/Jazz, and 01:00 local time on May 10 (20:00 UTC on May 9) at Ufone/PTML. Traffic was restored at 22:00 local time (17:00 UTC) on May 12.
Looking at Cloudflare Radar’s recently launched Internet Quality page for Pakistan during the duration of the shutdown, we observed that median latency within Pakistan dropped slightly after mobile networks were shut down, shown in the graph below. Prior to the shutdown, median latency (as observed to Cloudflare and a set of other providers) was in the 90-100ms range, while afterward, it averaged closer to 75ms. This may be a result of users shifting to lower latency fixed broadband connections – several fixed broadband providers in the country experienced increased traffic volumes while the mobile networks were unavailable.
Additional details about the mobile network shutdowns, content blocking, and the impact at an administrative unit and city level can be found in our May 12 blog post Cloudflare’s view of Internet disruptions in Pakistan.
Internet shutdowns are unfortunately frequent in India, with digital rights organization Access Now reporting at least 84 shutdowns within the country in 2022. The shutdowns are generally implemented at a more local level, and often last for a significant amount of time. One such shutdown took place in the northeastern Indian state of Manipur starting on May 3 after the escalation of ethnic conflict, and was reportedly intended to “thwart the design and activities of anti-national and anti-social elements… by stopping the spread of disinformation and false rumours'' and the likelihood of “serious disturbances to the entire peaceful coexistence of the communities and maintenance of public order”. Mobile data services were initially suspended for a five-day period, with the suspension continually extended through additional templated orders issued every five days.
The graphs below show the impact of the ordered shutdown to traffic from two major network providers in Manipur. Traffic from both AS45609 (Airtel) and AS9829 (BSNL) fell significantly around 18:00 local time (12:30 UTC) on May 4. Traffic on Airtel has remained low, and continued to drop further through the end of June. Traffic on BSNL showed slight signs of recovery starting in early June, but remains extremely low.
The shutdown order remains in place as of the time of this writing (late July).
On May 24, “Super Typhoon” Mawar wreaked havoc on the US territory of Guam, causing widespread physical damage after it made landfall, taking down trees, buildings, power lines, and communications infrastructure across the island. One result of this damage was a significant disruption to Internet connectivity, as shown in the country-level graph below. Restoration efforts started almost immediately, with Guam Power Authority, Docomo Pacific, and GTA Teleguam all posting regular status updates on their websites and/or social media accounts.
Among the two Internet providers, GTA Teleguam (AS9246) was largely able to complete service restoration in June, with traffic returning to pre-storm levels around June 17, as seen in the graph below. In fact, in a June 20 Facebook post they noted that “As of today, a majority of our wireless network cell sites are operational.” However, recovery at Docomo Pacific (AS3605) is taking significantly longer. The graph below shows that as of the end of June, traffic remained significantly below pre-storm levels.
On June 19, COTAS, a Bolivian telecommunications company, posted an update on their Facebook page that alerted users that a fiber optic cable had been cut in the town of Pongo. As seen in the graphs below, this cut significantly disrupted Internet connectivity across COTAS and two other network providers in the country: AS25620 (COTAS), AS27839 (Comteco), and AS52495 (Cotel) between 13:00 – 18:00 local time (17:00 – 22:00 UTC).
Gamtel, the state telecommunications company in The Gambia, notified subscribers via a Twitter post on June 7 of a localized fiber cut, and then of additional cable cuts on June 8. These fiber cuts disrupted Internet connectivity on AS25250 (Gamtel) between 14:00 local time on June 7 and 00:00 local time on June 9, with traffic volumes down as much as 80% as compared to the previous period. (The Gambia is UTC+0, so the local times are the same as UTC.)
An advisory posted on Twitter by Philippines telecommunications provider PLDT at 18:43 local time (10:43 UTC) on June 5 stated “One of our submarine cable partners confirms a loss in some of its internet bandwidth capacity, and thus causing slower Internet browsing. We are working with our partners to provide alternate capacity that would restore the browsing experience in the next few hours.” The traffic graph below shows a minor disruption to Internet traffic for AS9299 (PLDT) starting around 14:00 local time (06:00 UTC), and the “slower Internet browsing” noted by PLDT is evident in the Internet quality graphs below, with increased latency and decreased bandwidth evident around that same time. PLDT stated in a subsequent tweet that as of 06:22 local time on June 6 (22:22 UTC on June 5), “Our submarine cable partner confirms supplementing additional capacity, restoring browser experience.”
Aqualectra is the primary utility company in Curaçao, providing water and power services. On June 8, they posted a series of alerts to their Facebook page (1, 2, 3, 4) regarding a power outage impacting “all neighborhoods”, caused by a malfunction in one of the main power cables connected to the substation at Parera. This loss of power impacted Internet connectivity on the island, with a significant loss of traffic observed at a country level, as seen in the graph below, as well as across several Internet service providers, including AS11081 (UTS), AS52233 (Columbus Communications), and AS27660 (Curaçao Telecom). A followup Facebook post dated 01:25 local time on June 9 (05:25 UTC) confirmed the restoration of power to all neighborhoods.
A power outage at an Equinix data center in Prior Velho (near Lisbon) on the afternoon of June 6 affected local utilities, banking services, and court networks, according to published reports (1, 2). Portuguese Internet service provider MEO was also impacted by the power outage, which caused a drop in traffic for AS3243 (MEO-RESIDENCIAL) and AS15525 (MEO-EMPRESAS), seen in the graphs below. The disruptions caused by the power outage also impacted connectivity quality within Portugal, as the Radar Internet quality graphs below highlight – a concurrent drop in bandwidth and increase in latency is visible, indicating that end users likely experienced poorer performance during that period of time.
A countrywide power outage in Botswana on May 19 caused an Internet disruption that lasted about 90 minutes, from 10:45 until 12:15 local time (08:45 – 10:15 UTC), visible in the graph below. A tweet from Botswana Power Corporation provided public notice of the incident, but did not include a root cause.
On April 4, The Barbados Light & Power Company tweeted an “Outage Notice”, stating “We are aware that our customers across the island are currently without electricity.” Posted at 11:46 local time (15:46 UTC), the notice comes shortly after a significant drop in traffic was observed country-wide, indicating that the power outage also impacted Internet connectivity across the country. After posting several additional updates throughout the day, a final update posted at 18:00 local time (22:00 UTC) indicated that power had been restored to 100% of impacted customers. The graph below shows that traffic took several additional hours to return to normal levels. (Note that the orange highlighting in the graph represents the duration of the disruption, and the red shading is related to an internal data collection issue.)
A seven-hour Internet disruption observed in Namibia on June 15 and 16 was caused by unspecified “technical challenges” faced by Telecom Namibia. According to a tweet from the provider, “Telecom Namibia experienced technical challenges on its fixed and mobile data services on Thursday leading to intermittent Internet connectivity.” The impact of these challenges is visible in both the country- and network-level traffic graphs below.
Unspecified “technical reasons” also disrupted mobile Internet connectivity for Our Telekom customers in the Solomon Islands on April 26 and 27. An April 26 Facebook post from Our Telekom simply stated “Our mobile data network is currently down due to technical reasons.” The graphs below show a significant drop in traffic for AS45891 (Our Telekom/SBT) between 06:30 local time on April 27 (19:30 UTC on April 26) and 17:00 local time on April 27 (06:00 UTC). The loss of mobile traffic from Our Telekom also impacted traffic at a country level, as the graph shows a similar disruption for the Solomon Islands.
With an increasingly global service footprint, disruptions observed on SpaceX Starlink potentially impact users across multiple countries around the world. Just before midnight UTC on April 7, Internet traffic seen from AS14593 (SpaceX-Starlink) began to decline significantly. The disruption was short-lived, with traffic returning to expected levels within two hours. According to a Twitter post from Elon Musk, CEO of SpaceX, the problem was “Caused by expired ground station cert” (an expired digital certificate associated with one or more Starlink ground stations, likely preventing communication between the satellite constellation and the ground station(s)).
In Madagascar, a “problem with the backbone”, reported by Telma Madagascar, caused a loss of as much as two-thirds of Internet traffic between 09:15 – 14:00 local time (06:15 – 11:00 UTC) on April 7. The graphs below show that the backbone issue disrupted traffic at a national level, as well as for AS37054 (Telma Madagascar).
On April 4, UK Internet provider Virgin Media suffered multiple service disruptions that impacted Internet connectivity for broadband customers. The first outage started just before 01:00 local time (midnight UTC)l, lasting until approximately 09:00 local time (08:00 UTC). The second outage started around 16:00 local time (15:00 UTC), with traffic volumes going up and down over the next several hours before appearing to stabilize around 21:30 local time (20:30 UTC).
Virgin Media’s Twitter account acknowledged the early morning disruption several hours after it began, posting “We’re aware of an issue that is affecting broadband services for Virgin Media customers as well as our contact centres. Our teams are currently working to identify and fix the problem as quickly as possible and we apologise to those customers affected.” A subsequent post after service restoration noted “We’ve restored broadband services for customers but are closely monitoring the situation as our engineers continue to investigate. We apologise for any inconvenience caused.”
However, the second disruption was acknowledged on Virgin Media’s Twitter account much more rapidly, with a post at 16:25 UTC stating “Unfortunately we have seen a repeat of an earlier issue which is causing intermittent broadband connectivity problems for some Virgin Media customers. We apologise again to those impacted, our teams are continuing to work flat out to find the root cause of the problem and fix it.”
Although no additional details have been shared via social media by Virgin Media about the outages or their resolution, some additional information was shared via Twitter by an apparent customer, who posted “Virgin Media engineers re-seated fibre cards and reset hub equipment to restore service. TTL was extended as a workaround to maintain stability whilst a permanent fix is implemented.”
Additional details about the Virgin Media outage can be found in our April 4 blog post: Cloudflare’s view of the Virgin Media outage in the UK.
As we have covered in past blog posts, the physical war between Russia and Ukraine also has a very active online component, with traffic shifts, cyberattacks, and traffic rerouting all observed since the conflict began in February 2022. In early May 2022, we observed traffic from several Ukrainian network providers being rerouted through AS201776 (Miranda Media), a Crimean-based, Russian-controlled network operator. (This rerouting is discussed in more detail in two blog posts: Tracking shifts in Internet connectivity in Kherson, Ukraine and One year of war in Ukraine: Internet trends, attacks, and resilience.)
A little more than a year later, on May 26, we observed an Internet outage at Miranda Media. Traffic started to fall around 16:30 local time (13:30 UTC), dropping to zero around 18:15 local time (15:15 UTC). The outage disrupted connectivity on the Crimean Peninsula and parts of occupied Ukraine and lasted until approximately 06:00 local time on May 27 (03:00 UTC). Published reports (1,2) suggest that the outage was due to a cyberattack targeting Miranda Media, reportedly carried out by Ukrainian hacktivists.
Russian satellite provider Dozor Teleport, whose customers include Russia’s Ministry of Defense, ships of the Northern Fleet, Russian energy firm Gazprom, remote oil fields, the Bilibino nuclear power plant, the Federal Security Service (FSB), Rosatom, and other organizations, experienced a multi-hour outage on June 29. The outage, which occurred between 01:30 – 17:30 UTC, was reportedly the result of a cyberattack that at least two groups claimed responsibility for.
Multiple Internet disruptions occurred in Chad on April 23 and 24, impacting several Internet providers, and were ultimately visible at a country level as well. As seen in the graphs below, the outages occurred from 04:30 – 06:00 local time (03:30 – 05:00 UTC) and 15:00 – 20:00 local time (14:00 – 19:00 UTC) on April 23, and 04:00 – 08:30 local time (03:00 – 07:30 UTC) on April 24. The impacted network providers in Chad included AS327802 (Millicom Chad), AS327756 (Airtel Chad), AS328594 (Sudat Chad), and AS327975 (ILNET-TELECOM). The outages were reportedly caused by damage to fiber infrastructure that links Chad with neighboring Cameroon and Sudan, with the latter experiencing Internet service disruptions amid clashes between the Sudanese Armed Forces (SAF) and Rapid Support Forces (RSF).
As noted above, military action in Sudan disrupted Internet connectivity in Chad in April. Starting in mid-April, multiple Internet outages were observed at major Sudanese Internet providers, three of which are shown in the graphs below. The fighting in the country has led to fuel shortages and power cuts, ultimately disrupting Internet connectivity.
AS15706 (Sudatel) experienced complete Internet outages from 03:00 on April 23 to 17:00 on April 24 local time (01:00 on April 23 to 15:00 on April 24 UTC) and again from 03:00 on April 25 until 01:00 on April 28 local time (01:00 on April 25 to 23:00 on April 27 UTC). Internet connectivity on AS36972 (MTN) was disrupted between 03:00 and 12:00 local time on April 16 (01:00 – 10:00 UTC) and again between 20:00 on April 27 until 02:00 on April 29 (18:00 on April 27 to 00:00 on April 29). After a nominal multi-day recovery, a long-term near complete outage started on May 5, lasting for multiple weeks. Similar to MTN, multiple extended outages were also observed on AS33788 (Kanar Telecommunication). After seeing a significant drop in traffic midday on April 19, a near complete outage is visible between 12:00 on April 21 and 01:00 on April 29 (10:00 on April 21 to 23:00 on April 28 UTC), with a very brief minor recovery late in the day on April 24. A longer duration outage began around 00:00 local time on May 11 (22:00 on May 10 UTC), also lasting for multiple weeks.
Additional details about the Internet disruptions in Sudan can be found in our May 2 blog post: Effects of the conflict in Sudan on Internet patterns.
Repair work on the West Africa Cable System (WACS) submarine cable disrupted Internet connectivity across multiple countries, including Togo, Republic of Congo (Brazzaville), and Burkina Faso on April 6. According to the Google translation of a Facebook post from Canalbox Congo, the repair work was likely to cause “very strong disruptions on Internet connections with the risk of a total outage”. (Canalbox (GVA) is an African telecommunications operator that provides services across multiple countries in Africa.)
The graph below for AS36924 (GVA-Canalbox) shows three overlapping outage annotations, with each related to a disruption observed on that autonomous system (network) in one of the impacted countries. In the Republic of Congo (Brazzaville), a significant traffic disruption is visible between 16:15 – 23:15 local time (15:15 – 22:15 UTC). In Burkina Faso, the disruption happened earlier and was less severe, taking place between 09:15 – 18:00 local time (09:15 – 18:00 UTC), with a similar impact in Togo, where traffic was disrupted between 11:00 – 23:15 local time (11:00 – 23:15 UTC).
Because of how tightly interwoven the Internet has become with commerce, financial services, and everyday life around the world, any disruption to Internet connectivity ultimately carries an economic impact. The providers impacted by disruptions caused by unexpected or unavoidable events such as cable cuts or severe weather generally try to minimize the scope and duration of such disruptions, ultimately limiting the economic impact. However, in the case of government-directed Internet shutdowns, the damage to the economy is ultimately self-inflicted. The Internet Society’s new Net Loss Calculator now provides a way to quantify this damage, enabling the public, advocacy groups, and governments themselves to understand the potential cost of an Internet shutdown from gross domestic product (GDP), foreign direct investment (FDI), and unemployment perspectives.
Visit Cloudflare Radar for additional insights around Internet disruptions. Follow us on social media at @CloudflareRadar (Twitter), cloudflare.social/@radar (Mastodon), and radar.cloudflare.com (Bluesky), or contact us via email.
Post Syndicated from Боян Юруков original https://yurukov.net/blog/2023/dinko-i-kamionite-mu/
Вчера стана ясно, че камион се е обърнал блокирайки магистрала Тракия в двете посоки. Тривиална вече за нашия информационен канал история, която иначе би се загубила в потокът жлъч, кръв и скандали. Нещо обаче в отразяването на подробностите около случая ме подразни и реших да потърся сам информация.
За 20-тина минути излязоха доста неща, които описах в пост в социалките. Поради интереса добавих още в коментарите. Ще ги събера тук накратко и ще добавя накрая къде може да се правят такива проверки, ако някой има интерес. Надявам се най-малкото в националните ни медиите да започнат да го правят, защото това, на което сме свидетели е трагично.
Вече беше обявено, че камионът е на Господин Вълев Вълев по известен като Динко. Не, нямам никакво уважение към човека, просто първото му име наистина е „Господин“. Твърди, че имало метал и камъни по пътя, което от АПИ отричат, но добавят, че камионът е с изтекъл технически преглед от април и гумите били изключително изтъркани.
Припомням, че камионът е спукал гума, което се случва лесно при неизправни, поправяни незаконно или просто изпилени гуми, още повече при съмнения за претоварен камион, в резултат на което няколко коли са пострадали, няколко души са в болница, но като по чудо няма жертви.
Ето какво научаваме от регистрите:
Фирмата му е разследвана за данъчни измами, има множество санкции за нарушения с разрешителните за управление на отпадъци и други проблеми покрай тях, включително за нерегламентирана площадка, пожари и прочие. Отделно имаше скандал преди две години, в които със схема трябваше да се продаде цялата въздушно-контактна и канална високоволтова мрежа на Градски транспорт Пловдив за скрап на неговата фирма. Процедурата беше спряна и уж материалите са в прокуратурата. Познайте къде залежават.
Последното разрешително за управление на отпадъци му е от юни. Разрешителното за транспорт обаче е от 13-ти април и включва седем камиона. Още едно разрешително има за други три камиона на другата си фирма. Сред първите е злополучният от днес явно с номер A1256HH. На него му е изтекъл техническия преглед три дни по-рано – на 10-ти април. На още четири от камионите са им изтекли между февруари 2022 и март 2023, но това не пречи явно да са в разрешителното. И така до днес. Не пречи също, че два от тях все още също нямат гражданска.
Впрочем три от същите камиони без технически преглед, включително двата без гражданска, са вписани като средства за извършване на пътна помощ към 20 юни 2023.
Отделно в някои медии го хвалят, че докарал „уникален за района“ камион, който да изгребе отпадъците. Не се вижда точният номер, но изглежда да е със смолянска регистрация. В разрешителните от различните инспекции на която и да от фирмите му липсва камион с близка до тази регистрация, който да има право да превозва отпадъци.
За последните две години камионите му са насъбрали 17 нарушения, за които дължи компенсаторни такси за над 11 хиляди лева. Някои от тях са от 2021-ва. Един от камионите му – У0049АТ, с изтекъл гтп през септември 2022-ра, има регистрирано нарушение, че е карал без маршрутна карта през април 2023-та. Т.е. доказано е карал без ГТП и преди. Отделно двата му камиона Волво, включително този, който се блъсна днес, освен, че са без гтп, нямат нито една маршрутна карта, т.е. тол такса за пътищата в последно време. Включително за днес. Това е още едно нарушение отгоре на другите и отново не е отчитано дълго време.
Горе виждате карта на всички места, където камионите на Динко са хващани между юли 2021 и юни 2023, че не си плащат тол таксите като хората. В червено са местата, където е хващан два пъти. В синьо са местата, където е карал без ГТП и тол такса. В данните липсват двете нарушения на камионът A1256HH, който най-вероятно се е обърнал днес, защото май не е на името на фирмите му. Поне така може да съдим по регистъра отказващ справка по ЕИК. Най-много установени нарушения има през 2022-ра – 10.
От къде научаваме всичко това:
The post Динко, неговите камиони и една спяща държавна машина first appeared on Блогът на Юруков.
allroundo Pro – the World’s First Convertible, Modular Power Bank for On-the-Go
LITO, the Redefined Walkie-Talkie. Sleek, Versatile&Wearable
Post Syndicated from Александър Нуцов original https://www.toest.bg/natsionalniyat-suverenitet-i-natsionalniyat-populizum/
Селфи шоуто със Зеленски е отказ от национален суверенитет.
Твърдението е на бившия главен прокурор Иван Гешев и е част от публикацията му във Facebook от 8 юли във връзка с посещението на украинския президент Володимир Зеленски в България. Тук липсата на каквато и да е логическа или причинно-следствена връзка между понятието „национален суверенитет“ и снимките на политици и общественици със Зеленски не ни изненадва. Случаят обаче е показателен за твърде лековатата употреба на термини като „суверенитет“, „суверен“ и „национален интерес“ от бивши и настоящи високопоставени публични личности.
Тези думи, разбира се, представляват характерна част от политическото говорене. Проблемът настъпва тогава, когато се използват прекомерно, зле аргументирано и без конкретни уточнения. Това на практика ги обезличава до степен, в която публични фигури започват да си служат с тях при всевъзможни обстоятелства, както показва горният пример. Този тип боравене с думите сигнализира за популизъм и пропаганда, чрез които ораторът се стреми да постигне лични или партийни цели (например очерняне на опонент или трупане на електорат).
Подобен подход винаги е в ущърб на обществото, защото не просто обезсмисля ключови понятия, но създава погрешното усещане, че националният суверенитет и интереси са монолитни, непроменливи, застинали във времето величини, които принадлежат само и единствено на този, който ги артикулира. Така несъгласните с популистките тези автоматично се превръщат в „нарушители на националните интереси“, „безродници“ или „предатели“, което възпроизвежда черно-бели опростенчески възприятия и засилва обществената поляризация.
В деня на гласуването на кабинета „Денков“ например президентът Радев заяви, че се надява „правителството да не предава националните интереси“. Понятието „национален интерес“ е неизменна част от реториката на президента. Специфична за неговото говорене е липсата на конкретно определение в какво се изразява българският национален интерес (особено в контекста на войната в Украйна) и по-важното – защо то е правдоподобно.
Така, от една страна, Радев избягва потенциални неудобни въпроси и контрааргументи, които не могат да бъдат оборени (както показа срещата със Зеленски). От друга, президентът се опитва да изрази определена „истина“ от последна инстанция, като човек или трябва да припознае тезите му и да бъде зачетен като българин, или да им се противопостави и да бъде заклеймен като „безродник“. С подобно обладаване на понятия от национален (тоест от общ) характер ораторът (без значение от партийна си принадлежност и обществена длъжност) манипулира чувството ни за патриотизъм и национална принадлежност в името на собствени политически облаги.
Ако погледнем останалите европейски страни, ще забележим, че много партии и политици боравят с почти идентични прийоми за трупане на популярност. На състоялите се на 23 юли предсрочни парламентарни избори в Испания например популистката партия VOX на Сантяго Абаскал отново се нареди на трета позиция и спечели 33 места в парламента (с цели 19 по-малко от изборите през 2019 г.). Характерни за Абаскал са залегналите в партийната програма идеи за отвоюване на национален суверенитет от Европейския съюз, както и за отнемане на легалния статус на партии, асоциации и неправителствени организации, които според VOX накърняват териториалната цялост и суверенитет на Испания.
Това е класически пример за предлагане на лесни решения на сложни проблеми, засягащи в съответния случай европейската интеграция, от една страна, и противоречието между принципите за суверенитет и право на самоопределение, от друга. Решението на VOX, без да се представят ясни стъпки за реализацията му (вкл. оценка на негативните ефекти и последици), е да съсредоточи повече власт в националната държава. Това, разбира се, може да разпали националистки страсти и да привлече определен кръг от избиратели, но не отговаря на въпросите как такова решение може да се осъществи; какви ще бъдат щетите и санкциите от преразглеждане на отношенията със Съюза; от какви блага ще трябва да се лишат испанските граждани; или пък какви са рисковете от ескалация на напрежението при разрушаване на действащия модел на управление чрез ограничаване на автономните права на баските и каталунците например.
Засилването на националния суверенитет е неотменна тема и в реториката на немската дясна популистка партия „Алтернатива за Германия“ (Alternative für Deutschland, AfD). На 29 март 2023 г. партията дори предложи в парламента документ за суверенитета на Германия в рамките на ЕС. Той е насочен срещу подписаното през 2021 г. коалиционно споразумение и параграфа, посветен на бъдещето на ЕС (стр. 104), в който управляващата коалиция се ангажира да се бори за последващи стъпки към федерализация на Съюза в рамките на вече приключилата европейска инициатива „Конференция за бъдещето на Европа“.
AfD всъщност настоява правителството да се откаже от опитите за „превръщане на ЕС от общност на суверенни и равнопоставени национални държави в европейска федерална държава“. Според партията ЕС от години присвоява суверенитет от държавите членки, което води до „свръхрегулиране и забрани“ в ежедневието на гражданите. По тази причина AfD настоява Съюзът да се върне към „фундаменталните си ценности и цели“.
Интересен тук е парадоксът, че по същността си т.нар. „Конференция за бъдещето на Европа“ представлява серия от панели, дебати и инициативи, които дават трибуна на европейските граждани непосредствено да изразят идеите си за общо бъдеще. Ключово в случая е неформалното овластяване на европейските граждани да участват във формирането на общността. Прави впечатление, че по мислената вертикална линия индивид – държава – наднационална организация междинният и най-силен носител на власт и суверенитет – държавата, практически е прескочен в рамките на инициативата.
Това неформално прехвърляне на тежест при вземане на стратегически решения от държавата към гражданите (надолу) и международните организации (нагоре) е бавен, но важен процес, защото стимулира аргументирано съревнование на възгледи, включва в разговора широки кръгове от обществото и възпрепятства националните държави и техните управленски институции от злоупотреба с власт и еднолично налагане на политики.
Именно този пример може да използваме като начална точка за по-задълбочен разговор върху идеята за (национален) суверенитет и вторичните му аспекти в политическото говорене, като „национален интерес“, „национална сигурност“ и т.н. Най-напред е редно да отбележим, че суверенитетът е нееднородна величина. За него може да говорим от (международно)правна, политическа или културно-икономическа гледна точка, тоест в абстрактен/теоретичен или материален/физически смисъл. Той може да се отнася до упражняване на правомощия и власт от съответните органи в рамките на определена територия или до правата на различни играчи по отношение на външната политика и сигурността, които надхвърлят държавните граници.
Второ, суверенитетът няма нито абсолютна стойност, нито единен център (например държавата). Понятието „суверенитет“ еволюира, преобразява се и се адаптира към променящите се условия. Може да проследим зачеването му в европейската традиция чак до Вестфалската система от XVII в. С течение на времето разбирането за суверенитет претърпява дълбоки промени в резултат на знакови исторически събития.
Мирът след края на Втората световна война стъпва върху система от глобални организации, като ООН, Международния валутен фонд, Световната търговска организация и др., както и регионални, като Европейската общност за въглища и стомана, НАТО и др. Освен че носят със себе си ценности, принципи и норми, на които актьорите в международните отношения следва да се уповават, те получават определена власт и функции, присъщи до този момент единствено на националните държави.
Процесите на глобализация и нарастващата свързаност между страните допълнително засилват ролята им за усъвършенстване на международноправните отношения и регулирането на сфери като сигурност, валутна политика, търговия, инвестиции и т.н. Суверенитетът се „разпръсква“ и надолу – към гражданите с увеличаването на техните права, а също и под формата на децентрализация на властта. Следователно националната държава постепенно губи ролята си на единствен център на суверенитет (макар да си остава най-силният).
И трето, рамките, в които се простират националният суверенитет и произлизащите от него национални интереси, зависят от индивидуалните особености, история и народопсихология на всяка отделна държава. Разбирането за суверенитет и национален интерес съдържа в себе си известна приемственост и памет, които възпрепятстват опитите за изкуственото им монополизиране в политическото говорене.
В България например модерното разбиране за суверенитет и национални интереси е тясно свързано с целите за присъединяване към Европейския съюз и НАТО, дефинирани в началото на 90-те години, след разпада на СССР и тоталитарния режим на Тодор Живков. Именно приемствеността на това разбиране в днешно време играе ролята на естествена преграда срещу опитите за радикални отклонения въпреки засилената пропаганда, медийна дезинформация и популисткото обладаване и опростяване на идеята за суверенитет от редица политици и политически формирования в контекста на руската инвазия в Украйна.
Post Syndicated from Bruce Schneier original https://www.schneier.com/blog/archives/2023/07/fooling-an-ai-article-writer.html
World of Warcraft players wrote about a fictional game element, “Glorbo,” on a subreddit for the game, trying to entice an AI bot to write an article about it. It worked:
And it…worked. Zleague auto-published a post titled “World of Warcraft Players Excited For Glorbo’s Introduction.”
[…]
That is…all essentially nonsense. The article was left online for a while but has finally been taken down (here’s a mirror, it’s hilarious). All the authors listed as having bylines on the site are fake. It appears this entire thing is run with close to zero oversight.
Expect lots more of this sort of thing in the future. Also, expect the AI bots to get better at detecting this sort of thing. It’s going to be an arms race.
Post Syndicated from Михаил Ангелов original https://www.toest.bg/nauchni-novini-mehanizmi-za-predpazvane-ot-bolesti-fukushima-kentavur/
Имунната ни система има много механизми, с които да ни предпази от нашественици. Но за да не се обърне срещу нас, тя има нужда и от начин да идентифицира нашите клетки. Един от тях са протеини, които са разположени по повърхността на клетките и се кодират от HLA гените. При тези протеини се наблюдава силен полиморфизъм – те са много различни и рядко се среща сходство при отделни хора. Активното им участие в имунната система води до клиничното им значение при трансплантации, автоимунни, ракови и заразни болести.
Открита е и интересна връзка с COVID-19 и безсимптомното протичане на заболяването при някои хора. Оказва се, че при носителите на специфичен вариант на HLA-B гена, T-клетките от имунната система са по-подготвени за отговор на вируса. Хипотезата на учените е, че дори да не са се срещали с него, клетките успяват да го разпознаят благодарение на сходството му с често срещаните коронавируси, причинители на настинките.
Поне едно копие на варианта HLA-B*15:01 е открито в около 10% от пациентите с европейско потекло, включени в изследването. При хомозиготните носители (с две копия на варианта, получени от двамата родители) вероятността за безсимптомно протичане е осем пъти по-висока. От данните се вижда, че в групата, която няма симптоми, около 20% са носители на варианта, докато в другата група той се открива само в 9%. Това кара учените да изкажат хипотезата, че наличието на варианта обуславя по-малка вероятност от развитие на симптоми, като ефектът е адитивен (с натрупване).
Данните за изследването са взети от доброволци, включени в голяма база с донори на костен мозък (NMDP). Едно от изследванията за съвместимост, което се прави с цел намиране на подходящ донор за пациенти, нуждаещи се от трансплантация, е именно генотипиране на HLA вариантите. Информацията за COVID-19 е събрана с помощта на мобилно приложение, в което всеки е можел да попълни здравния статус и симптомите си.
Такава база с донори се поддържа и у нас и всеки на възраст от 18 до 50 години и в добро здравословно състояние може да се регистрира като донор. В последно време вече се разчита повече на извличането на периферни стволови клетки (ПСК), които се откриват в ниска концентрация в кръвта. Количеството им може да се увеличи с медикаменти, които предизвикват засиления им синтез от костния мозък, а след това ПСК се извличат от кръвта с помощта на апарат за афереза. Процедурата е много по-лека от даряването на костен мозък, тъй като не е свързано с оперативна намеса.
В общ план атомната енергия все още е важен елемент от стратегията за генериране на електроенергия на фона на глобалните климатични промени. За съжаление, инцидентите в този тип електроцентрали са колкото редки, толкова и значими в природозащитен, икономически и човешки аспект. Аварията в атомната централа „Фукушима I“ през 2011 г. е втората (след „Чернобил“ от 1986 г.) от седма степен по международната скала за ядрени и радиационни събития. Вследствие на земетресение и последвало цунами части от структурата на работещите блокове бяха нарушени, което доведе до изпускане на радиоактивен материал.
Горивото в реакторите остава горещо за дълго време, което налага да се охлаждат с вода. Но тя се замърсява радиоактивно, ставайки опасен отпадък, и в момента се съхранява в стоманени резервоари, намиращи се на територията на централата. Там се събират също подпочвена и дъждовна вода от територията около централата, радиоактивно замърсена в резултат на аварията. Периодично Токийската електрическа компания (TEPCO) предупреждаваше, че мястото за построяване на нови резервоари намалява, а през 2021 г. обяви плановете си за контролирано освобождаване на тази вода в океана в рамките на няколко десетилетия. Към момента са събрани над 1,3 млн. тона, достатъчни да напълнят над 500 басейна с олимпийски размери.
Преди изпускането ѝ водата ще бъде пречистена с помощта на специална филтрираща система (ALPS), която премахва над 60 радиоактивни изотопа от нея. Този процес е одобрен от Международната агенция за атомна енергия (МААЕ) към ООН и се следи внимателно от експертите ѝ. За съжаление, технологията не е напълно ефективна и някои изотопи остават в доловими количества (като цезий-137 и стронций-90), а премахването на други е невъзможно. Един от тях е тритият – изотоп на водорода, в който има два неутрона, липсващи в най-често срещаната форма, и е с период на полуразпад 12,3 години.
Плановете на компанията са преди изпускането водата да се разреди така, че концентрацията на тритий да падне под допустимите граници на СЗО за питейна вода. На това се дължи и дългият период, предвиден за изпразването на резервоарите. Според редица изказвания от страна на японските власти и МААЕ място за тревога няма – вода, съдържаща изотопа, се изпуска от много атомни електроцентрали, и то в концентрации, по-високи от планираните за „Фукушима“.
Например най-мащабният център за преработка на ядрено гориво, разположен във Франция, годишно изпуска неколкократно повече тритий, отколкото се намира във всички резервоари в централата. Също той се счита за сравнително безопасен, тъй като е източник на бета-радиация, поради което няма достатъчно енергия да проникне през кожата. Риск за здравето има при поглъщане на по-големи количества, например чрез замърсена риба. Изотопът се задържа в тялото между 7 и 14 дни, като най-практичният антидот е да се пие повече вода, защото най-често той влиза в организма под формата на свръхтежка вода. На база на всичко това МААЕ дава зелена светлина за започване на процедурата през втората половина на 2023 г.
Въпреки официалното разрешение от регулаторните органи повечето реакции са отрицателни. Най-силни са от съседните държави, които са и сред най-големите вносители на морски дарове от Япония. Например Хонконг възнамерява да забрани вноса от 10 японски префектури, ако започне изпускането на резервоарите. В Южна Корея рибари протестираха срещу решението, към което правителството е положително настроено. Недоволство е изказано и от представител на японската асоциация на рибарските кооперативи, според когото трябва да се намери друг вариант за справяне със замърсената вода.
Китайската реакция е още по-остра – в изявление на говорителя на Министерството на външните работи в няколко точки се изразява мнение, че технологията за пречистване на водата все още не е доказана, а TEPCO е обвинена в укриване и манипулиране на данни. Заключението е, че „Тихият океан не е отходен канал на Япония“ и решението не трябва да се взема еднолично. За ситуацията не помагат и съобщенията, че през последната година неколкократно е хващана риба с високо радиационно съдържание във водите покрай отвеждащите тръби на централата. През май в такъв улов е открит радиоактивният изотоп цезий-137 в концентрация 180 пъти над разрешените нива.
Все още няма ясна дата за началото на изпразването на резервоарите, но японското правителство активно дебатира както с граждански организации, така и на международно ниво, призовавайки за вяра в науката и съвременните технологии. За момента изглежда, че решението на правителството и TEPCO е окончателно, но не се знае дали икономическият риск от намаляване на износа и обтегнатите отношения със съседите на Япония няма да го забави или промени. От друга страна, отработената вода продължава да се натрупва и предприемането на действия не може да се отлага дълго.
Планетарната система PDS 70 се намира на около 370 светлинни години от Земята, в съзвездието Кентавър. Тя е от голям интерес за астрономите, тъй като е в началото на формирането си и тепърва в нея ще се образуват планети и луни и орбитите им ще се стабилизират. Звездата в центъра ѝ е сравнително млада (на около 5,4 млн. години) и е от спектрален клас K. Тези звезди са по-малки и по-студени от нашето Слънце, но дават няколко предимства за развитие на живот в обитаемата им зона – стабилният им цикъл е по-дълъг и отделят по-малко ултравиолетови лъчи.
В орбита около звездата са открити два газови гиганта, подобни на Юпитер, както и впечатляващ пръстен, в който най-вероятно се формират още планети. Единият от гигантите – PDS 70c, вече се сдоби със славата на първия със забелязан около него облак, от който ще се образуват естествени спътници.
С помощта на най-големия радиотелескоп в света ALMA, намиращ се в чилийската пустиня Атакама, е направено друго наблюдение, което може да се окаже първо по рода си – откриване на екзотроянец в далечната система.
Троянските обекти са интересни тела, чиято орбита обикновено съвпада с орбитата на по-голямо тяло, намиращо се на 60 градуса преди или след тях. Това са две от стабилните точки в орбитите, наричани точки на Лагранж: L4, намираща се преди основното тяло, и L5 – след него. Троянските обекти са добре познато явление в нашата Слънчева система – почти всички планети имат такива. В повечето случаи те не са много, например за Земята са известни два и се намират в L4, като вторият (2020 XL5) е сравнително ново откритие от 2020 г. Юпитер, от друга страна, освен с размера си, впечатлява и с броя на троянските обекти в своята орбита. До момента са описани над 11 000, приблизително две трети от които се движат преди него.
Новото откритие е облак, движещ се в орбитата на другата планета – PDS 70b, но не е ясно дали той тепърва ще се обособи в нова планета, или представлява останки от такава. Теоретичната възможност за съществуване на троянски обекти със сходна маса е лансирана отдавна, но до момента подобни обекти не са били открити. Възможно е редкостта им да е следствие от нестабилността на орбитите им за по-дълъг период и затова първото наблюдение да е в млада система. Повече информация ще бъде получена през 2026 г., когато планетата и съпътстващият облак от фрагменти ще са изминали достатъчно разстояние и учените ще могат да проверят дали продължават да се движат в тандем.
Откритието е изключително вълнуващо, защото, освен че е от значение за науката, потвърждението за съществуването на екзотроянците има и по-интригуваща страна – това означава, че е възможно да има две планети със сходен размер, климат и дължина на годината, които са изключително близо една до друга.
В системата има и втори, по-малък акреционен диск, който се намира в областта между звездата и пространството, разчистено от PDS 70b и потенциалния му партньор. Ширината на диска покрива разстояние от около 160 млн. км, което попада в т.нар. обитаема зона за този клас звезди. С помощта на детектора в средния инфрачервен спектър MIRI на космическата обсерватория „Джеймс Уеб“ учени от Института по астрономия „Макс Планк“ в Хайделберг са отчели, че в диска се съдържа вода под формата на пара.
За момента произходът на водата не е напълно ясен. Възможно е тя да се образува на място при свързването на водород и кислород в проста поредица от реакции. Условията в системата позволяват и пренасяне на частици с лед от външната към вътрешната част, което може да е допълнителен източник за вътрешния планетообразуващ облак. Счита се, че водните молекули не се разпадат, защото частиците, изграждащи облака, ги защитават от ултравиолетовите лъчения на звездата.
Въз основа на данните може да се предположи, че ако там се образуват планети, те ще имат на разположение вода още в най-ранните етапи на процеса. Комбинирано с класа на звездата и попадането им в обитаемата ѝ зона, това подсказва голяма вероятност да се получат планети, сходни със Земята. Отдалечеността им от нас ги прави недостъпни заради технологичното ни развитие към момента, но ни дава възможност да разберем повече за формирането на нашата планета, а също така ни насочва какви признаци да търсим в по-близки системи.
Post Syndicated from Ben Durbin original https://www.raspberrypi.org/blog/our-focus-on-impact/
The mission of the Raspberry Pi Foundation is to enable young people to realise their full potential through the power of computing and digital technologies. That’s what we say in our 2025 strategy. But how can we be sure we’re succeeding?
In our strategy we also identify one of our values as being ‘focussed on impact’. This means that we are committed to learning from the best available evidence, and to being rigorous and transparent about the difference we’re making.
Like all our values, our focus on impact infuses all of our work, and it is led by a dedicated impact team. This blog outlines four ways in which we put this value into practice in pursuit of our mission.
It doesn’t matter how fast you run, if you’re heading in the wrong direction, you’ll never get to your destination. We use data to prioritise our resources where we can make the biggest difference for young people.
For example, we use national statistics from the UK to assess how many of the Code Clubs and CoderDojos we support in the UK run in places where they can reach young people facing educational disadvantage, so that we can adopt an evidence-based approach to better serving these young people.
And we know many of the young people who face the greatest barriers to accessing computing education and developing new skills and confidence live in countries with low- and middle-income economies. That’s why we are building new partnerships in India, Kenya, and South Africa and adapting our resources and programmes for the contexts of educators and learners living there.
We’re really excited that we’ll soon be publishing an updated Theory of Change, which captures how we make an impact. This will be the foundation for Monitoring and Evaluation (M&E) plans for all of our initiatives, where we specify their goals and set down what kinds of data we will collect to make sure we have the measure of whether the initiatives are succeeding.
Strong M&E is equally important for our established programmes and our new pilot initiatives. Code Club, the worldwide network of free, after-school coding clubs for 9- to 13-year-olds we support, has been growing for more than 10 years. Durham University’s Evidence Centre for Education is currently conducting an independent evaluation of UK-based Code Clubs to help us understand how to better support Code Club volunteers and learners around the world. We ourselves recently evaluated the pilot of a new programme we designed in partnership with Amala Education to deliver a vocational skills course for displaced learners aged 16 to 25 in Kakuma refugee camp in Kenya.
Data is only useful if it’s translated into insights that are acted upon. We use the findings from evaluations to inform the design and continual improvement of all our initiatives.
For example, the evaluation of our pilot vocational skills training in Kakuma refugee camp provided insights that have helped us adapt the programme for a second cohort of young people. The same was true of the M&E insights we gained from our partnership with Mo Schools in Odisha, India, where we have provided training and support to 1075 teachers to establish Code Clubs. Informed by survey data and informal feedback each step of the way, we are now gradually scaling up our support towards launching a more intensive computing and coding programme in 2000 schools in Odisha this year.
Side by side with our M&E results, we also rely on the latest computing education research, conducted at the Foundation, in the Raspberry Pi Computing Education Research Centre at the University of Cambridge, and by academic researchers around the world. Our groundbreaking research programme on gender balance in computing, and our ongoing research on culturally relevant pedagogy, are shaping the way we work to enable all young people to achieve their full potential in computing.
We are proud of the difference we are making. We want everyone to hear about it and feel inspired to get involved in our vital mission for young people. Our annual reviews are packed full of statistics and overviews of the difference we’re making, and we’re creating a growing video series of unique stories from people in the community we support. Watch this space for news about our updated Theory of Change, our next annual review, and more blogs about our impact.
By doing these four things well, we can be confident that we are enabling young people to achieve their potential through the power of computing and digital technologies.
If you share our passion for impact and think our mission is important, why not get involved today? You can:
The post The four elements of our focus on impact appeared first on Raspberry Pi Foundation.
Post Syndicated from original https://lwn.net/Articles/938712/
The LWN.net Weekly Edition for July 27, 2023 is available.
Post Syndicated from original https://lwn.net/Articles/938769/
The U-Boot
“universal boot loader” is used extensively in the embedded-Linux world.
At the 2023 Embedded
Open Source Summit (EOSS), Simon Glass gave a presentation (slides,
YouTube video) on
the status of the project, with a focus on new features added over the last
several years. He also wanted to talk about complexity in the firmware
world, which he believes is increasing, and how U-Boot can help manage that
complexity. The talk was something of a grab bag of ideas and changes
throughout the increasingly large footprint of the project.
Post Syndicated from Noritaka Sekiyama original https://aws.amazon.com/blogs/big-data/end-to-end-development-lifecycle-for-data-engineers-to-build-a-data-integration-pipeline-using-aws-glue/
Data is a key enabler for your business. Many AWS customers have integrated their data across multiple data sources using AWS Glue, a serverless data integration service, in order to make data-driven business decisions. To grow the power of data at scale for the long term, it’s highly recommended to design an end-to-end development lifecycle for your data integration pipelines. The following are common asks from our customers:
To tackle these asks, this post defines the development lifecycle for data integration and demonstrates how software engineers and data engineers can design an end-to-end development lifecycle using AWS Glue, including development, testing, and CI/CD, using a sample baseline template.
Today, it’s common to define not only data integration jobs but also all the data components in code. This means that you can rely on standard software best practices to build your data integration pipeline. The software development lifecycle on AWS defines the following six phases: Plan, Design, Implement, Test, Deploy, and Maintain.
In this section, we discuss each phase in the context of data integration pipeline.
In the planning phase, developers collect requirements from stakeholders such as end-users to define a data requirement. This could be what the use cases are (for example, ad hoc queries, dashboard, or troubleshooting), how much data to process (for example, 1 TB per day), what kinds of data, how many different data sources to pull from, how much data latency to accept to make it queryable (for example, 15 minutes), and so on.
In the design phase, you analyze requirements and identify the best solution to build the data integration pipeline. In AWS, you need to choose the right services to achieve the goal and come up with the architecture by integrating those services and defining dependencies between components. For example, you may choose AWS Glue jobs as a core component for loading data from different sources, including Amazon Simple Storage Service (Amazon S3), then integrating them and preprocessing and enriching data. Then you may want to chain multiple AWS Glue jobs and orchestrate them. Finally, you may want to use Amazon Athena and Amazon QuickSight to present the enriched data to end-users.
In the implementation phase, data engineers code the data integration pipeline. They analyze the requirements to identify coding tasks to achieve the final result. The code includes the following:
When using AWS Glue, you can define the data integration logic in a job script, which can be written in Python or Scala. You can use your preferred IDE to implement AWS resource definition using the AWS Cloud Development Kit (AWS CDK) or AWS CloudFormation, and also the business logic of AWS Glue job scripts for data integration. To learn more about how to implement your AWS Glue job scripts locally, refer to Develop and test AWS Glue version 3.0 and 4.0 jobs locally using a Docker container.
In the testing phase, you check the implementation for bugs. Quality analysis includes testing the code for errors and checking if it meets the requirements. Because many teams immediately test the code you write, the testing phase often runs parallel to the development phase. There are different types of testing:
For unit testing, even for data integration, you can rely on a standard testing framework such as pytest and ScalaTest. To learn more about how to achieve unit testing locally, refer to Develop and test AWS Glue version 3.0 and 4.0 jobs locally using a Docker container.
When data engineers develop a data integration pipeline, you code and test on a different copy of the product than the one that the end-users have access to. The environment that end-users use is called production, whereas other copies are said to be in the development or the pre-production environment.
Having separate build and production environments ensures that you can continue to use the data integration pipeline even while it’s being changed or upgraded. The deployment phase includes several tasks to move the latest build copy to the production environment, such as packaging, environment configuration, and installation.
The following components are deployed through the AWS CDK or AWS CloudFormation:
AWS CodePipeline helps you to build a mechanism to automate deployments among different environments, including development, pre-production, and production. When you commit your code to AWS CodeCommit, CodePipeline automatically provisions AWS resources based on the CloudFormation templates included in the commit and uploads script files included in the commit to Amazon S3.
Even after you deploy your solution to a production environment, it’s not the end of your project. You need to monitor the data integration pipeline continuously and keep maintaining and improving it. More specifically, you also need to fix bugs, resolve customer issues, and manage software changes. In addition, you need to monitor the overall system performance, security, and user experience to identify new ways to improve the existing data integration pipeline.
Typically, you have multiple accounts to manage and provision resources for your data pipeline. In this post, we assume the following three accounts:
If you want, you can use the same account and the same Region for all three.
To start applying this end-to-end development lifecycle model to your data platform easily and quickly, we prepared the baseline template aws-glue-cdk-baseline using the AWS CDK. The template is built on top of AWS CDK v2 and CDK Pipelines. It provisions two kinds of stacks:
The AWS Glue app stack provisions the data integration pipeline, including the following resources:
The following diagram illustrates this architecture.
At the time of publishing of this post, the AWS CDK has two versions of the AWS Glue module: @aws-cdk/aws-glue and @aws-cdk/aws-glue-alpha, containing L1 constructs and L2 constructs, respectively. The sample AWS Glue app stack is defined using aws-glue-alpha, the L2 construct for AWS Glue, because it’s straightforward to define and manage AWS Glue resources. If you want to use the L1 construct, refer to Build, Test and Deploy ETL solutions using AWS Glue and AWS CDK based CI/CD pipelines.
The pipeline stack provisions the entire CI/CD pipeline, including the following resources:
The following diagram illustrates the pipeline workflow.
Every time the business requirement changes (such as adding data sources or changing data transformation logic), you make changes on the AWS Glue app stack and re-provision the stack to reflect your changes. This is done by committing your changes in the AWS CDK template to the CodeCommit repository, then CodePipeline reflects the changes on AWS resources using CloudFormation change sets.
In the following sections, we present the steps to set up the required environment and demonstrate the end-to-end development lifecycle.
You need the following resources:
To initialize the project, complete the following steps:
We use a virtual environment in order to isolate the Python environment for this project and not install software globally.
After this step, the subsequent steps run within the bounds of the virtual environment on the client machine and interact with the AWS account as needed.
default-config.yaml based on your environments (replace each account ID with your own):
pytest to initialize the snapshot test files by running the following command:
Run the following commands to bootstrap your AWS environments:
When you use only one account for all environments, you can just run the cdk bootstrap command one time.
Run the command using the pipeline account to deploy the resources defined in the AWS CDK baseline template:
This creates the pipeline stack in the pipeline account and the AWS Glue app stack in the development account.
When the cdk deploy command is completed, let’s verify the pipeline using the pipeline account.
On the CodePipeline console, navigate to GluePipeline. Then verify that GluePipeline has the following stages: Source, Build, UpdatePipeline, Assets, DeployDev, and DeployProd. Also verify that the stages Source, Build, UpdatePipeline, Assets, DeployDev have succeeded, and DeployProd is pending. It can take about 15 minutes.
Now that the pipeline has been created successfully, you can also verify the AWS Glue app stack resource on the AWS CloudFormation console in the dev account.
At this step, the AWS Glue app stack is deployed only in the dev account. You can try to run the AWS Glue job ProcessLegislators to see how it works.
In an earlier step, you cloned the Git repository from GitHub. Although it’s possible to configure the AWS CDK template to work with GitHub, GitHub Enterprise, or Bitbucket, for this post, we use CodeCommit. If you prefer those third-party Git providers, configure the connections and edit pipeline_stack.py to define the variable source to use the target Git provider using CodePipelineSource.
Because you already ran the cdk deploy command, the CodeCommit repository has already been created with all the required code and related files. The first step is to set up access to CodeCommit. The next step is to clone the repository from the CodeCommit repository to your local. Run the following commands:
In the next step, we make changes in this local copy of the CodeCommit repository.
Now that the environment has been successfully created, you’re ready to start developing a data integration pipeline using this baseline template. Let’s walk through end-to-end development lifecycle.
When you want to define your own data integration pipeline, you need to add more AWS Glue jobs and implement job scripts. For this post, let’s assume the use case to add a new AWS Glue job with a new job script to read multiple S3 locations and join them.
First, implement and test the AWS Glue job and its job script in your local environment using Visual Studio Code.
Set up your development environment by following the steps in Develop and test AWS Glue version 3.0 and 4.0 jobs locally using a Docker container. The following steps are required in the context of this post:
public.ecr.aws/glue/aws-glue-libs:glue_libs_4.0.0_image_01.
If the workspace folder is not shown, choose Open folder and select /home/glue_user/workspace.
Then you will see a view similar to the following screenshot.
Optionally, you can install AWS Tool Kit for Visual Studio Code, and start Amazon CodeWhisperer to enable code recommendations powered by machine learning model. For example, in aws_glue_cdk_baseline/job_scripts/process_legislators.py, you can put comments like “# Write a DataFrame in Parquet format to S3”, press Enter key, then CodeWhisperer will recommend a code snippet similar to the following:
Now you install the required dependencies described in requirements.txt to the container environment.
Now let’s make the required changes for a new AWS Glue job here.
ProcessLegislators in order to add the new AWS Glue job JoinLegislators:
Here, you added three job parameters for different S3 locations using the variable config. It is the dictionary generated from default-config.yaml. In this baseline template, we use this central config file for managing parameters for all the Glue jobs in the structure <stage name>/jobs/<job name>/<parameter name>. In the proceeding steps, you provide those locations through the AWS Glue job parameters.
aws_glue_cdk_baseline/job_scripts/join_legislators.py:
aws_glue_cdk_baseline/job_scripts/tests/test_join_legislators.py:
prod and dev:
"jobs" in the variable config in tests/unit/test_glue_app_stack.py, tests/unit/test_pipeline_stack.py, and tests/snapshot/test_snapshot_glue_app_stack.py (no need to replace S3 locations):
If the Run button is not shown, install Python into the container through Extensions in the navigation pane.
Then you can verify that the newly added unit test passed successfully.
pytest to initialize the snapshot test files by running following command:
Complete following steps to deploy the AWS Glue app stack to the development environment and run integration tests there:
You can see that the pipeline is successfully triggered.
There is nothing required for running the integration test for the newly added AWS Glue job. The integration test script integ_test_glue_app_stack.py runs all the jobs including a specific tag, then verifies the state and its duration. If you want to change the condition or the threshold, you can edit assertions at the end of the integ_test_glue_job method.
Complete the following steps to deploy the AWS Glue app stack to the production environment:
GluePipeline.DeployProd stage.
Wait for the DeployProd stage to complete, then you can verify the AWS Glue app stack resource in the dev account.
To clean up your resources, complete following steps:
In this post, you learned how to define the development lifecycle for data integration and how software engineers and data engineers can design an end-to-end development lifecycle using AWS Glue, including development, testing, and CI/CD, through a sample AWS CDK template. You can get started building your own end-to-end development lifecycle for your workload using AWS Glue.
Noritaka Sekiyama is a Principal Big Data Architect on the AWS Glue team. He works based in Tokyo, Japan. He is responsible for building software artifacts to help customers. In his spare time, he enjoys cycling with his road bike.
Post Syndicated from original https://lwn.net/Articles/939332/
The extensible scheduler class enables the
creation of CPU schedulers in BPF. After the fourth
version of this series was greeted with relative silence, Tejun Heo asked about
the status of this work:
We are comfortable with the current API. Everything we tried fit
pretty well. It will continue to evolve but sched_ext now seems
mature enough for initial inclusion. I suppose lack of response
doesn’t indicate tacit agreement from everyone, so what are you
guys all thinking?
Scheduler maintainer Peter Zijlstra gave
him his answer: “I’m still hating the whole thing with a
“. He went on to make it clear that this work will not be
passion
merged into the mainline. So, it seems, developers wanting to try their
hand at BPF scheduler development will need to apply an out-of-tree patch
series, for now at least.
Post Syndicated from Drew Burton original https://blog.rapid7.com/2023/07/26/etr-cve-2023-35078-critical-api-access-vulnerability-ivanti-in-endpoint-manager-mobile/
CVE-2023-35078 is a remote unauthenticated API access vulnerability in Ivanti Endpoint Manager Mobile, which was previously branded as MobileIron Core. The vulnerability has a CVSS v3 base score of 10.0 and has a severity rating of Critical.
Ivanti has reported that they have received information from a credible source indicating active exploitation of CVE-2023-35078. A vendor supplied patch to remediate CVE-2023-35078 was released on July 24, 2023.
Ivanti Endpoint Manager Mobile (EPMM) is used to configure and manage mobile devices and enforce security policies on those devices. According to Ivanti’s advisory, if exploited, CVE-2023-35078 enables an unauthorized, remote (internet-facing) actor to potentially access users’ personally identifiable information and make limited changes to the server.
On July 24, 2023, the Norwegian National Security Authority (NSM) released a statement that CVE-2023-35078 was used in a zero-day attack to successfully compromise the Norwegian Security and Service Organization (DSS). Additionally, the US Cybersecurity & Infrastructure Security Agency (CISA) has also released an advisory for the vulnerability as well as adding the vulnerability to their Known Exploited vulnerabilities (KEV) catalog.
According to CISA’s advisory, the vulnerability allows a remote unauthenticated attacker to access personally identifiable information (PII) and add an administrator account on the affected EPMM server, to allow for further system compromise.
The Shadowserver project has listed 2,729 IP addresses on the internet that remain vulnerable to the issue (as of July 24, 2023).
Currently, no known public exploit code is available (as of July 26, 2025). If public exploit code becomes available, we expect more broad exploitation of vulnerable internet-facing systems. Organizations running the affected software are advised to apply the vendor patch as soon as possible.
Please note: Information on affected versions or requirements for exploitability may change as we learn more about the threat.
CVE-2023-35078 affects all supported versions of Ivanti Endpoint Manager Mobile (EPMM) prior to the vendor patch:
Product versions no longer receiving support are also affected, and Ivanti has released a workaround as part of their response.
Ivanti has released the following patches to remediate the issue:
Instructions to install the patch or workaround are available on Ivanti’s KB article (which requires a free login to access).
An unauthenticated (remote) check will be available to InsightVM customers in tonight’s (July 26, 2023) content release.
Post Syndicated from Patrick Kennedy original https://www.servethehome.com/lattepanda-sigma-review-the-raspberry-pi-alternative-with-in-band-ecc-and-faster-than-a-mac-mini/
This LattePanda Sigma packs TB4, NVMe SSDs, an Intel CPU faster than an Apple Mac Mini M2, in-band ECC, and Arduino into a HDD size SBC
The post LattePanda Sigma Review The Raspberry Pi Alternative with In-Band ECC and Faster than a Mac Mini appeared first on ServeTheHome.
Post Syndicated from Channy Yun original https://aws.amazon.com/blogs/aws/new-amazon-ec2-p5-instances-powered-by-nvidia-h100-tensor-core-gpus-for-accelerating-generative-ai-and-hpc-applications/
In March 2023, AWS and NVIDIA announced a multipart collaboration focused on building the most scalable, on-demand artificial intelligence (AI) infrastructure optimized for training increasingly complex large language models (LLMs) and developing generative AI applications.
We preannounced Amazon Elastic Compute Cloud (Amazon EC2) P5 instances powered by NVIDIA H100 Tensor Core GPUs and AWS’s latest networking and scalability that will deliver up to 20 exaflops of compute performance for building and training the largest machine learning (ML) models. This announcement is the product of more than a decade of collaboration between AWS and NVIDIA, delivering the visual computing, AI, and high performance computing (HPC) clusters across the Cluster GPU (cg1) instances (2010), G2 (2013), P2 (2016), P3 (2017), G3 (2017), P3dn (2018), G4 (2019), P4 (2020), G5 (2021), and P4de instances (2022).
Most notably, ML model sizes are now reaching trillions of parameters. But this complexity has increased customers’ time to train, where the latest LLMs are now trained over the course of multiple months. HPC customers also exhibit similar trends. With the fidelity of HPC customer data collection increasing and data sets reaching exabyte scale, customers are looking for ways to enable faster time to solution across increasingly complex applications.
Introducing EC2 P5 Instances
Today, we are announcing the general availability of Amazon EC2 P5 instances, the next-generation GPU instances to address those customer needs for high performance and scalability in AI/ML and HPC workloads. P5 instances are powered by the latest NVIDIA H100 Tensor Core GPUs and will provide a reduction of up to 6 times in training time (from days to hours) compared to previous generation GPU-based instances. This performance increase will enable customers to see up to 40 percent lower training costs.
P5 instances provide 8 x NVIDIA H100 Tensor Core GPUs with 640 GB of high bandwidth GPU memory, 3rd Gen AMD EPYC processors, 2 TB of system memory, and 30 TB of local NVMe storage. P5 instances also provide 3200 Gbps of aggregate network bandwidth with support for GPUDirect RDMA, enabling lower latency and efficient scale-out performance by bypassing the CPU on internode communication.
Here are the specs for these instances:
| Instance Size |
vCPUs | Memory (GiB) |
GPUs (H100) |
Network Bandwidth (Gbps) |
EBS Bandwidth (Gbps) |
Local Storage (TB) |
| P5.48xlarge | 192 | 2048 | 8 | 3200 | 80 | 8 x 3.84 |
Here’s a quick infographic that shows you how the P5 instances and NVIDIA H100 Tensor Core GPUs compare to previous instances and processors:
P5 instances are ideal for training and running inference for increasingly complex LLMs and computer vision models behind the most demanding and compute-intensive generative AI applications, including question answering, code generation, video and image generation, speech recognition, and more. P5 will provide up to 6 times lower time to train compared with previous generation GPU-based instances across those applications. Customers who can use lower precision FP8 data types in their workloads, common in many language models that use a transformer model backbone, will see further benefit at up to 6 times performance increase through support for the NVIDIA transformer engine.
HPC customers using P5 instances can deploy demanding applications at greater scale in pharmaceutical discovery, seismic analysis, weather forecasting, and financial modeling. Customers using dynamic programming (DP) algorithms for applications like genome sequencing or accelerated data analytics will also see further benefit from P5 through support for a new DPX instruction set.
This enables customers to explore problem spaces that previously seemed unreachable, iterate on their solutions at a faster clip, and get to market more quickly.
You can see the detail of instance specifications along with comparisons of instance types between p4d.24xlarge and new p5.48xlarge below:
| Feature | p4d.24xlarge | p5.48xlarge | Comparision |
| Number & Type of Accelerators | 8 x NVIDIA A100 | 8 x NVIDIA H100 | – |
| FP8 TFLOPS per Server | – | 16,000 | 640% vs.A100 FP16 |
| FP16 TFLOPS per Server | 2,496 | 8,000 | |
| GPU Memory | 40 GB | 80 GB | 200% |
| GPU Memory Bandwidth | 12.8 TB/s | 26.8 TB/s | 200% |
| CPU Family | Intel Cascade Lake | AMD Milan | – |
| vCPUs | 96 | 192 | 200% |
| Total System Memory | 1152 GB | 2048 GB | 200% |
| Networking Throughput | 400 Gbps | 3200 Gbps | 800% |
| EBS Throughput | 19 Gbps | 80 Gbps | 400% |
| Local Instance Storage | 8 TBs NVMe | 30 TBs NVMe | 375% |
| GPU to GPU Interconnect | 600 GB/s | 900 GB/s | 150% |
Second-generation Amazon EC2 UltraClusters and Elastic Fabric Adaptor
P5 instances provide market-leading scale-out capability for multi-node distributed training and tightly coupled HPC workloads. They offer up to 3,200 Gbps of networking using the second-generation Elastic Fabric Adaptor (EFA) technology, 8 times compared with P4d instances.
To address customer needs for large-scale and low latency, P5 instances are deployed in the second-generation EC2 UltraClusters, which now provide customers with lower latency across up to 20,000+ NVIDIA H100 Tensor Core GPUs. Providing the largest scale of ML infrastructure in the cloud, P5 instances in EC2 UltraClusters deliver up to 20 exaflops of aggregate compute capability.
EC2 UltraClusters use Amazon FSx for Lustre, fully managed shared storage built on the most popular high-performance parallel file system. With FSx for Lustre, you can quickly process massive datasets on demand and at scale and deliver sub-millisecond latencies. The low-latency and high-throughput characteristics of FSx for Lustre are optimized for deep learning, generative AI, and HPC workloads on EC2 UltraClusters.
FSx for Lustre keeps the GPUs and ML accelerators in EC2 UltraClusters fed with data, accelerating the most demanding workloads. These workloads include LLM training, generative AI inferencing, and HPC workloads, such as genomics and financial risk modeling.
Getting Started with EC2 P5 Instances
To get started, you can use P5 instances in the US East (N. Virginia) and US West (Oregon) Region.
When launching P5 instances, you will choose AWS Deep Learning AMIs (DLAMIs) to support P5 instances. DLAMI provides ML practitioners and researchers with the infrastructure and tools to quickly build scalable, secure distributed ML applications in preconfigured environments.
You will be able to run containerized applications on P5 instances with AWS Deep Learning Containers using libraries for Amazon Elastic Container Service (Amazon ECS) or Amazon Elastic Kubernetes Service (Amazon EKS). For a more managed experience, you can also use P5 instances via Amazon SageMaker, which helps developers and data scientists easily scale to tens, hundreds, or thousands of GPUs to train a model quickly at any scale without worrying about setting up clusters and data pipelines. HPC customers can leverage AWS Batch and ParallelCluster with P5 to help orchestrate jobs and clusters efficiently.
Existing P4 customers will need to update their AMIs to use P5 instances. Specifically, you will need to update your AMIs to include the latest NVIDIA driver with support for NVIDIA H100 Tensor Core GPUs. They will also need to install the latest CUDA version (CUDA 12), CuDNN version, framework versions (e.g., PyTorch, Tensorflow), and EFA driver with updated topology files. To make this process easy for you, we will provide new DLAMIs and Deep Learning Containers that come prepackaged with all the needed software and frameworks to use P5 instances out of the box.
Now Available
Amazon EC2 P5 instances are available today in AWS Regions: US East (N. Virginia) and US West (Oregon). For more information, see the Amazon EC2 pricing page. To learn more, visit our P5 instance page and explore AWS re:Post for EC2 or through your usual AWS Support contacts.
You can choose a broad range of AWS services that have generative AI built in, all running on the most cost-effective cloud infrastructure for generative AI. To learn more, visit Generative AI on AWS to innovate faster and reinvent your applications.
— Channy