From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from AUS01-SY4-obe.outbound.protection.outlook.com (mail-sy4aus01on2107.outbound.protection.outlook.com [40.107.107.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id E6AE43B2A4 for ; Mon, 3 Jun 2024 06:40:31 -0400 (EDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LMwVubt2kPNpiBARwT3aRSdSZ08KmhlUj5oJTIzX3R6h5wXuyvt7SyFhfzqLiMF7MZPi/uLLKcdq50L+weGqLWxGp+yzq0TOGJEpjqES7Vv+yx9QUt6/8b0PLhGfh68SzSBGdilE0kF3hersGbXfeX+cXTkAO5drSpgE9+wLvq5ls9bQf1QcoOlvZXXAR6nbQW/vZA+OFOYQyulOwzKC2KiQLRB0kCNjmSQoPV6Q0PQnLExf9WndL0sJOgT2eo+WyLV+pglE+yIQ8dp7Lk7EtqZDZAfZi2VnCQ6h6Ha1ZiclhygZpdMDSiATJ2Zt7qsXaH3hFupe0E9vxX4Y9HmhPg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JCZtWY+uBRCaUYfah6tob22e3vdIqiUL7uS/LkpqCGw=; b=MvM4CEq3hopcIEVgezC2vDhV1YkzZjWaQ2TqzsVVgpfeuG3ZMv0U5ibKFyhjEMr7K9xINjFYtu9xhTZH9Spxlc/e16Rs3bSlvTA5R6azh9/o92HvxbPhIciYQ4uk55C+l/TZC7JlD1liiqZcY2zFcAEM2rxVasd+VPSHJeGY3ypf3D21fyYsxerZGOYqxd1I/WjVATfXhgqz+klPm0ZhctbDaFapOKloCVse2dlQ5ZDzye3WK26fwZJKw+OKTzytQ9KlUxixXWBZ/Z6WlVF6jeQqU2/MUMEYGLVqXX0PIbh5ufilZKx0yZFsdc7Nv/EubUxQPWBwiEpRK5exiFMdkQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=auckland.ac.nz; dmarc=pass action=none header.from=auckland.ac.nz; dkim=pass header.d=auckland.ac.nz; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JCZtWY+uBRCaUYfah6tob22e3vdIqiUL7uS/LkpqCGw=; b=AySChGudnEQGpHeJOQlmEX1BPfklzIOEFhlKQGqNUalTnNjw1i9H7sJcQdXpq+BJB3Yj2o2yKc/R2xkC/FKgIjspS4voIPPFwT6W1Oy22MpK4obeAplQKI002BNiPmidcwUXU7XgzABjy7A+lDlF0b35Qj8aThVgC/Pk/3I1uMQ= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=auckland.ac.nz; Received: from SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM (2603:10c6:10:297::19) by ME0P300MB0487.AUSP300.PROD.OUTLOOK.COM (2603:10c6:220:230::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7633.19; Mon, 3 Jun 2024 10:40:28 +0000 Received: from SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM ([fe80::2100:96f2:f11b:4fc2]) by SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM ([fe80::2100:96f2:f11b:4fc2%7]) with mapi id 15.20.7633.021; Mon, 3 Jun 2024 10:40:28 +0000 Content-Type: multipart/alternative; boundary="------------Fp0H0euFyJO0Jg000UejmTb0" Message-ID: <00d881ed-682e-4ab9-8cad-ba5aea318251@auckland.ac.nz> Date: Mon, 3 Jun 2024 22:40:24 +1200 User-Agent: Mozilla Thunderbird To: starlink@lists.bufferbloat.net References: Content-Language: en-US From: Ulrich Speidel In-Reply-To: X-ClientProxiedBy: SY5P282CA0052.AUSP282.PROD.OUTLOOK.COM (2603:10c6:10:20a::11) To SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM (2603:10c6:10:297::19) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY8P300MB0544:EE_|ME0P300MB0487:EE_ X-MS-Office365-Filtering-Correlation-Id: f748f8a9-771c-4530-95e7-08dc83b99589 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230031|376005|1800799015|366007; X-Microsoft-Antispam-Message-Info: =?utf-8?B?NTJFdFIvbHJnQ3BIVmgzNWhLbURNMTFYVFMrQUhZN3orVEZYWWw0RjdIYnRK?= =?utf-8?B?SFJUWWdYRzZkVU9xcUY1bE1vRGwrUlNIUDlPamNDdEREdHF5VW1mdGVuNUc2?= =?utf-8?B?WWp1MjcwMC9NbVIzSnhpWXlMWFZ3YlBka3ROOVdPOW5zcmd0eDdGaW01eUh6?= =?utf-8?B?T3BCcmlyamtUZXJUM1FQa0NuL1lHRE8wOS9OMHBYTmNKVVZuUUZlR2x4V0Jh?= =?utf-8?B?bkxFWjF6UWdkdHdoL3lyUUZZZk5jTzg2VDUzZndwS0J1emc2OGtsV1V0VnRB?= =?utf-8?B?Y1pFTXNGMWZLLzh6Qk9DcU1Ud01meHlLQ1U0UVUyZzNpUGZsZFMvUVlnYWQ5?= =?utf-8?B?cGtyTFo0RDZNTmh1YmlGUXhoR0FKUHMzNHp3UU1HYzRSY3QyWGNHSXUzS1pX?= =?utf-8?B?TFlVMXFELzJacFhOSk9lc1ZpQXFZUGx6bE1KQllUdEtwZGJmNlh0SDduQ2c3?= =?utf-8?B?MTYrV2FvOW51ZVJCK1UxUzh5M0lUUi9ON3ZGREcrWW5iUUFNSzgzclo5TWxp?= =?utf-8?B?enhXcEVRTFVYYjR6L3VYbDk0M2VQalZtK1dBc01uSm00K201K2dka0lIRE1k?= =?utf-8?B?cXRwN1BqZUgwb2MxdFFtZ2FOalJ0d0RqUVlEbWdnU0E4VjFpaW5yUFl0TDlH?= =?utf-8?B?QzhlMGxWbnMvMU13WmhEYVQ3TXZjdkxES0tHcVR3UUdOVmVQdG1OYXVUZXVk?= =?utf-8?B?TXNKSUVScURVdFRlNkJSdDh4VGVoc3hJWEVkYnZ5NGZpMlBaRnhVVGRuVS80?= =?utf-8?B?bWl1UFN1RGRCZE1pbTNnalNrcFlTc2RscUlzWVllb3o5SjFmcUtMU2VGUGZU?= =?utf-8?B?MDdRSVpEeU93RUJhRjAzQTd6UXRQMTJ5UVBjTUdzd0IvQmZzZm9xSDZ6My9P?= =?utf-8?B?ejRZY01VcUZWOTJ4WlR0dy8zVGxkRWViL2hKV0hLUFpjVDdxZm9zOHU1d1Ro?= =?utf-8?B?Wm9pSkxhWDZnSnB5Z3IwaVI1S0lPNjZzaEgvdEdrVzE4UzI2elM5Y0ttZnRX?= =?utf-8?B?RHA1SGd5QURyUnJzLzUzTkRXaE41NFROclJOZ1hUSFJhckgrSlFGb2NKU0cr?= =?utf-8?B?TFlzVEZQQmRVWCt1UG1ZcXErSWRQK3prRGRJeTJxRUpteU9vOUJ2c0VHOFJk?= =?utf-8?B?ekZ0bUVycGMrUm9CcVoyNUFxY3k2ODE0ZzRCLzBDOC8wUzA4QVJtODU3U3JQ?= =?utf-8?B?cTdkdXg0WXZORTZPSE5FOFJLRzk1bVN0L3lyVnVPT1RVWnlGZi9CYjhzQ1E3?= =?utf-8?B?SDFnM0hXL3VYYnZZQU80Z1prQnJlNDJxTjViNGM3cWtwWGF6UkZHWnFKSGVF?= =?utf-8?B?TzUxWXlhbVJlNnNsQVRVSGlURjI1VDlkV1FkQnlyRmxiWnd5KzNtbGFOcnVI?= =?utf-8?B?WWZLV0M1c296RUdreHBnTHNzTC95akQzd3I3cHpXc1c2NXR3UXRGQ2JzWlFJ?= =?utf-8?B?cmYwcXQrS2FFVkJGWjE0NkRCalg4OHNuRng1azFkdndwQmY0Z2hXVHdOMWVZ?= =?utf-8?B?YUtkMlgyemo3RzJRTGNoeXFzK2NSY2NWRzI3WXJySXpucXllbjBsemI5VGxK?= =?utf-8?B?WkNLZGRUR2RCTDlpMkhtTlowVStoMFk4YzBZLzAvaHJpL0hGc21MMHMzdUIv?= =?utf-8?Q?FHgmf8Sy7i3kNVS45hycxkaBjj83mu/XR5tFQHAswsBw=3D?= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230031)(376005)(1800799015)(366007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MzkwdVNwOTdqYmRORTRma0pvM3UydkFhamFTQkcwYjRuUUx3N1p0TkNEcWUy?= =?utf-8?B?MllHb2kzazlWeVFXcmFWVUgvUUhnbkIzWjBNcjcxdnBLSlFxcEN4L0FDMTRU?= =?utf-8?B?QTU2ZzIwSFR3MERLRnY0RHlkaitvVVpyc2JyTSszUlIwNEJKeGVjWGxXN1B5?= =?utf-8?B?ZXNrUmUvaWNqZ1dLY2hmMWNyclA0OENOc2h3RUVlR2xqL1NaMEZsMURtR3B2?= =?utf-8?B?bTZXa0d4UUFyd2RZRnROSmNpdW1xQTNJbkZiZ0paWGpzNGNpS21OQlpBTzFa?= =?utf-8?B?L1ZWd3MyTGovSFp0L2ZBSFlHU2NObE5OKzRxZ0RKSVp6Y1Q0UTBHUmdoL2xm?= =?utf-8?B?L1hrcHJZNGcrSnBOR1BUd1NZdDZpeFRrMEdUdU1jWlNIMWZKKzVXWXNzcDZM?= =?utf-8?B?QTJvMGFaNXVkVEtaTzR4bkpnVnUwRFhFS3VaNjd0VTFlaDFXdlg5TkNSemdw?= =?utf-8?B?YkdLSjBTWmUvNDVpbE1sT0ZMeEt5OUJtQ1ZzNEdhS2NrSmh0VUpjUUJrdVQx?= =?utf-8?B?RE5Id29CQkxESndMOHBjdXpsOThlSGhiZzNUNkh3Mm1PY3NjQ1ZMcFRyczIx?= =?utf-8?B?alFxWFJ3M1ByWEhFS1pLU0dXcG5ZRDI3UW9mMlpiM0NBM0RXWk54S25pSXo2?= =?utf-8?B?OHBETDJsMmlra256WGZhb3pqTzQyUXdwYzRxTGt2ZnY0SFJ1Q3A4eUlYaUNP?= =?utf-8?B?VjY1OWdEaUptOUNYYm9tS0VsdEYxalZCRmJiOU9KenRLR3BIQkNxTjlBQXB4?= =?utf-8?B?V0FjdmtoMllBMks4NytLRTJaQTJTdndFOGhvRjY2aW1HMno2ZXozaDhpVitO?= =?utf-8?B?eVBDRXNhN2QwajFNV2pzZlhqdk9ZcUkvVTIxaWZ0RG8yRmk4SmVVK0ZxVUFD?= =?utf-8?B?N0hmUXFOWEFXdjVjclBZRmNiL0VzR1dmY0txZm5zVklyVEdoejQyRUxRSXB0?= =?utf-8?B?RFpkaFJFK3ZFNUhZMkJoL0JXd2hyT2ZKVm9iU1lSRFcxM3ZjRmF2WHFYbTRM?= =?utf-8?B?SjR3MEsyYkdlbm5lcmgweXFvUGhFTFVhQlo3WFA1dXgxYS9HaTM1STJranBK?= =?utf-8?B?bS9QTFBaWTB1SWpPbzVWOWVVaWo5QVFxci9yeElLNExhM1hWNmh4MmtWY3Zt?= =?utf-8?B?OXh1YTVSTkorOXR3c0RkTzlvcG91RCs5Z2M2UElBbHVkWW9VcDJQTVdNcldj?= =?utf-8?B?K2cvYVRkeWV1S295VDhuSUErZlJyUUxmL2k0SVNDbU5FSGNqL05JbmxEVG9z?= =?utf-8?B?VlVhVlRhLzdHUnE4YzBwaUY1bm1JbUNzOXlzL0pwRG9TcTZQVTVKa2ZxV21l?= =?utf-8?B?NU9hYzBpREt4TzZpY0lLUnZkZHFIUDF3NEUxQ2tnVXcxTjVFL1pCam1laGRS?= =?utf-8?B?amNVNTV0WXF2cHYrM2UyYUdxY2R3RUVBemJISWduZ2ZzVXpSbTMrcGl2cGp0?= =?utf-8?B?NG5nTU5Td0pOaVF6UytRV2wxSklmeG8zT2tXNldoRTIvU2o4V3FLaEl6ZmFn?= =?utf-8?B?dnpJOU01K0grZXBjbm1jL3Y0NnFSUm9sWm1Lc3FRdlgwckZpVEhmT0xqbVJK?= =?utf-8?B?bWgzUHZkQ3YwM3pHaWVncU1xQXo3TmdONTdDVmU4c1dzY3RDSnpPUUZEa3VW?= =?utf-8?B?N3hHdVZhMWdPdGZWYXBVREZabFk4elJ3VE1oUDR3Kzl4eFdkbmNtMnFWeFJG?= =?utf-8?B?OTFiN1dxdUNCa2MvdVBkeWdManB0RVFTUngzYmhEOFBMUFl2TzErUWY5WklE?= =?utf-8?B?eldYT3FIZVpoMWJEemx5K1R1Z2hLM1QzY2Rzbmx4cUMyZzZML1puNkR3UGtT?= =?utf-8?B?alBFUWxIS3FFem1sOVJyTFF5M2VmNkJxRWFiL01RbWt0amxncVZTcnhtTTYy?= =?utf-8?B?eDF5cFAweXNTSzdibXMycGhOdklLcnRFY29CckQ1MFoxQ2pDYlNnWlFaeVMr?= =?utf-8?B?YlRiaDVCanozeXo5UTJySytkMkVmMzN4QytYMlZUR0pHOUt2UVh3V3dEbjJo?= =?utf-8?B?SnBXcjRKSDVvK3ptQWtaMGVjck9wOUVIV1FqUW82ZWRkZktDb2VoUGlMUXlH?= =?utf-8?B?MTBXU0dubkZUZTNvVGNDa0lMUkxsNDFGTkhCS0ZMVFZDcUVkdnRFRXhJTWNH?= =?utf-8?B?RWY5czVaVCtlbnlQQ0x1NEVQckpJNExWSW02M3J6cFZadEhJQ3lDbGI1VTkv?= =?utf-8?B?SjJ3cHFPWEVhcDhSa0N4SHlmMEZtenZCVCtWVloxZklldjB3MnFjU2JOMjky?= =?utf-8?B?RkFiOE1uS0tIU2R6TWpWUzROZU5BPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: f748f8a9-771c-4530-95e7-08dc83b99589 X-MS-Exchange-CrossTenant-AuthSource: SY8P300MB0544.AUSP300.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Jun 2024 10:40:28.1604 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d1b36e95-0d50-42e9-958f-b63fa906beaa X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zdgTXwQZcIfCb/3Y1xBhyHKj0UZbV7enGu2Qm4b7nFGxmqyWB9VAmlIxdA83dpnCwRt/2tS3Z3HieS44qUIiMK5tXX4jX+JcvOilFIn2IGA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME0P300MB0487 Subject: Re: [Starlink] musk: 28ms median latency on starlink X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2024 10:40:32 -0000 --------------Fp0H0euFyJO0Jg000UejmTb0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Getting the satellite density up will help, but it will only improve things so far. The problem on user downlink in particular is that there's a limit on the maximum spectral power flux density that arrives from the satellite in space on the ground. If you point all (mutually compatible) user downlink beams from a single satellite at a single cell, you all but reach that limit there. In fact, where SpaceX want to use two beams on the same frequency but with opposite polarisations to the same cell, they must reduce the transmit power on each beam by 3 dB (50%) in order to stay within the limit. More satellites would give you more beams, but you can't point them at cells that already have a beam on the same frequency in use from another satellite (unless you de-rate on the power front, I guess). That seriously limits what you can receive in terms of total capacity within a single cell to what a single satellite's mutually compatible beams can deliver, which appears to be about 12 Gb/s on V1 and V1.5 birds, and 20 Gb/s on V2 (on Ku, if you add in Ka-band and anticipate Dishys that can do Ka, then it's a lot more for Ka). In practice, we know that a cell gets served by beams from different satellites, but the overall constraint still applies - if you deploy beam X from sat A and beam Y from sat B to the same cell, this makes the same contribution to PFD as deploying both from the same satellite. Note that Starlink sats do have multiple mutually incompatible beams that they can only point at different cells, bringing Ku user downlink capacity up to 16 Gb/s on V1 and 1.5, and 48 Gb/s on V2. But that only ups your chances of getting a larger slice of those 12 or 20 Gb/s in your cell. Your best bet for continuing good service at the moment is literally to tell your neighbours that Starlink is useless, so they don't sign up and you can have your cake all to yourself ;-) On 3/06/2024 5:13 am, Dave Taht via Starlink wrote: > Via elon musk: > > Starlink just achieved a new internal median latency record of 28ms > yesterday! Great work by the engineering and operations teams. > > - https://twitter.com/elonmusk/status/1797282250574184587 > > I of course, am very interested in y'all´s external measurements of > how well starlink is doing. For me, it is fantastic - 30Mbit uploads > nowadays, 0 > latency on the upload (how?) > https://www.waveform.com/tools/bufferbloat?test-id=2a1d139b-87cb-4ba4-a829-e2167801cffe > > I also keep hoping that the rest of the ISP industry is now paying > attention and deploying stuff like fq_codel and cake and libreqos, > but, ah well - I will settle for starlink blowing past a lot of dsl > and cable and finding ways to get their density up. > > Anyone going to the Starship launch on the 6th? > > > > -- > https://www.youtube.com/watch?v=BVFWSyMp3xg&t=1098s > Waves Podcast > Dave Täht CSO, LibreQos > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink -- **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------Fp0H0euFyJO0Jg000UejmTb0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Getting the satellite density up will help, but it will only improve things so far.

The problem on user downlink in particular is that there's a limit on the maximum spectral power flux density that arrives from the satellite in space on the ground. If you point all (mutually compatible) user downlink beams from a single satellite at a single cell, you all but reach that limit there. In fact, where SpaceX want to use two beams on the same frequency but with opposite polarisations to the same cell, they must reduce the transmit power on each beam by 3 dB (50%) in order to stay within the limit. More satellites would give you more beams, but you can't point them at cells that already have a beam on the same frequency in use from another satellite (unless you de-rate on the power front, I guess). That seriously limits what you can receive in terms of total capacity within a single cell to what a single satellite's mutually compatible beams can deliver, which appears to be about 12 Gb/s on V1 and V1.5 birds, and 20 Gb/s on V2 (on Ku, if you add in Ka-band and anticipate Dishys that can do Ka, then it's a lot more for Ka). In practice, we know that a cell gets served by beams from different satellites, but the overall constraint still applies - if you deploy beam X from sat A and beam Y from sat B to the same cell, this makes the same contribution to PFD as deploying both from the same satellite. Note that Starlink sats do have multiple mutually incompatible beams that they can only point at different cells, bringing Ku user downlink capacity up to 16 Gb/s on V1 and 1.5, and 48 Gb/s on V2. But that only ups your chances of getting a larger slice of those 12 or 20 Gb/s in your cell.

Your best bet for continuing good service at the moment is literally to tell your neighbours that Starlink is useless, so they don't sign up and you can have your cake all to yourself ;-)

On 3/06/2024 5:13 am, Dave Taht via Starlink wrote:
Via elon musk:

Starlink just achieved a new internal median latency record of 28ms yesterday! Great work by the engineering and operations teams.

- https://twitter.com/elonmusk/status/1797282250574184587

I of course, am very interested in y'all´s external measurements of how well starlink is doing. For me, it is fantastic - 30Mbit uploads nowadays, 0

I also keep hoping that the rest of the ISP industry is now paying attention and deploying stuff like fq_codel and cake and libreqos, but, ah well - I will settle for starlink blowing past a lot of dsl and cable and finding ways to get their density up.

Anyone going to the Starship launch on the 6th?



--
Dave Täht CSO, LibreQos

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink

-- 
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

The University of Auckland
u.speidel@auckland.ac.nz 
http://www.cs.auckland.ac.nz/~ulrich/
****************************************************************
--------------Fp0H0euFyJO0Jg000UejmTb0--