From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from au-smtp-delivery-117.mimecast.com (au-smtp-delivery-117.mimecast.com [103.96.23.117]) (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 CE48C3B29E for ; Sat, 18 Feb 2023 05:25:21 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auckland.ac.nz; s=mimecast20200506; t=1676715919; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=npi1VneKVBOa9YfodWiqUOa1X5/BsMlUk34QdRfVEF4=; b=FMRHFh9nGLusbPtR2eaRwT0xhihNNp9GmeyJ/5R7Wpa1JV+M5ylN7K03ilSp6umh7jLu7h IKxpN0ZjftF8ADYeui7yFdUGbwzcJPCHbbnKrZFAcp0BNaOqlFgUUMNFyyAqEB+LidKNWD fykbpRcwtrXphx+qt6wfdtsZLCqjFNw= Received: from AUS01-ME3-obe.outbound.protection.outlook.com (mail-me3aus01lp2234.outbound.protection.outlook.com [104.47.71.234]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id au-mta-72-_Ii2aAr7PwWFv4-uYNsUbQ-1; Sat, 18 Feb 2023 21:25:16 +1100 X-MC-Unique: _Ii2aAr7PwWFv4-uYNsUbQ-1 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) by ME3PR01MB7243.ausprd01.prod.outlook.com (2603:10c6:220:151::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6134.14; Sat, 18 Feb 2023 10:25:14 +0000 Received: from SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::7d2c:5b99:cacb:ba54]) by SY4PR01MB6979.ausprd01.prod.outlook.com ([fe80::7d2c:5b99:cacb:ba54%7]) with mapi id 15.20.6134.014; Sat, 18 Feb 2023 10:25:14 +0000 Message-ID: <59d5e2b7-ee1e-9019-fb98-3a81fd8bf545@auckland.ac.nz> Date: Sat, 18 Feb 2023 23:25:12 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 To: Michael Richardson Cc: Bruce Perens , "starlink@lists.bufferbloat.net" References: <09f3a84a-c48b-5709-c32b-9bf6cdcd0b3f@auckland.ac.nz> <20200.1676648584@localhost> From: Ulrich Speidel In-Reply-To: <20200.1676648584@localhost> X-ClientProxiedBy: SYBPR01CA0129.ausprd01.prod.outlook.com (2603:10c6:10:5::21) To SY4PR01MB6979.ausprd01.prod.outlook.com (2603:10c6:10:142::13) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SY4PR01MB6979:EE_|ME3PR01MB7243:EE_ X-MS-Office365-Filtering-Correlation-Id: 03b6062a-62d1-43ef-9af4-08db119a6c7e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0 X-Microsoft-Antispam-Message-Info: /jVTXcvsWq5mB6QyGn0xn/zRK++JV8zxprLg/uThGYHCecfPDt7ujf7JTQUeIhIQxgITDUrDQYiTW8AnhAXIH5/x+sV5MqMyT5ZpkUiBnolWz2lUp7XRT8IrPgtale9ctqoYgQtUUcpZmzTjnLeqYkux4LNOCjB3bL80Nt7+sWfgiEkEX1TinA0vsu7AA1MQAgqfmH8ZKWHZDER6eSiPLjodyY+vv/zE8iNmEl1hiBqMyad0Wvxa9OVFBK1wnS9WpDOK8kS2CBQG9I1eiHmLj+I4FzPuziJKApckpqs0ip8jKga+P5aGX4O65o6j7Uxol8Arz3sgcTb809w/J8kO0YMArgBZYXIx3RDuoUNCMvpHDaqK8FhX41NLcO8bKf5zJZZH3Os7ZBQ9Pia3tclWTBCLj4nZfAUH6zhF46KIzp0UW5LW9NH3MiOoeLyYYwKvKL1iUPjRbmD78pKT81Ij1ORTQ6Nn2z6dqSXlgjMjgOEHdNgiBmOqGWGb6ap/Qp3AbYrAJG6udDRjdPATiqOVGUakzaq0c477BhzGEHgcBmHkU+XpaA7fXx8W3ITSY/n4H8j2BfDVKTYzotcDg9113zgoCauCpuR83GRiGT1JHy0HmU4ocQc98sUL92yjI9biN+w4L/3lKXla7TRGUtFmIuGST4y+vpIGeZ8kvYUiQdtO/xga86my8YheJTGM4gb5rSoaCJGP43DRf5pZxoW+isHnzGh8ERsH5AR4Rm7wnSU= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SY4PR01MB6979.ausprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(346002)(39860400002)(366004)(396003)(376002)(451199018)(66476007)(66946007)(6916009)(4326008)(8676002)(66556008)(6486002)(966005)(31696002)(316002)(786003)(54906003)(166002)(2906002)(36756003)(5660300002)(8936002)(41300700001)(38100700002)(33964004)(53546011)(186003)(6512007)(86362001)(6506007)(83380400001)(31686004)(2616005)(66574015)(478600001)(43740500002)(45980500001); DIR:OUT; SFP:1101 X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?TzltVlBaSnVJa0NsdytOY3Jlb2k4eGh4a3pqall4ZTIrYWovZUZpUW9hZmls?= =?utf-8?B?VUkzK1daYWJvcXE5Y0pIU1hqeW5XRHptd3FOYWxnTHlQbjNJME1FdVI5SkJj?= =?utf-8?B?a3lIV0djQjMzVnRjN014bW1yVm1hdzNxQ0J6eUVDQ1BqRVQwaTVSTGZGb2pY?= =?utf-8?B?M2RmZUQ1UGYrM3htNlYvNGUwZytJMER2NEt1WlFHVmY4SXFoY0NUNFdobjdZ?= =?utf-8?B?N0tPQ205TS85K1l6MkVvaW9FdDlwQy8vSHgzaTRPVHVla1hyaFdZa3NQelhj?= =?utf-8?B?VGw5NGJ2T0VoOHJYQS9ZZm04dVhtc0dNYy9tZ0RnRHZhWEZkc1prV1JDL1Vi?= =?utf-8?B?dkpkdFhyWmxlSXlzUmIyZFRucUVMWUlEWE1mOEFIQWRDZEkwb1M4a2lFdG1K?= =?utf-8?B?ZjhpaGpaRm9GYkdzUDVhU1ZWRDdCZXlvckVlbGZJeGNwaVRmd0l0KzVybktj?= =?utf-8?B?UTQyN2xPTlRBWEJzb09lUmVWeFFQLytUVlc5cFFPbDFmdUR5ekorOVBVUzgz?= =?utf-8?B?N1lEUEk3YnR3a3MxeWpITmt1bWI1MjRtOVlCTVdQczZkMmNLaE1WL0ZyRWdm?= =?utf-8?B?b1lsbytXTENiZG0vblBlK2Y4VjVnNTdJbWN4eGRRbmw1MXpyZXJ3WDhUQTl6?= =?utf-8?B?dXVwOEc0SUxTQzM2Q1FCUTBKa2JYUGhCbjF2UzZHTEJJTlZMUG5OajgrTVB6?= =?utf-8?B?L2RRQk5hWUhrNGNPVmFiWE1WYmZnelRhRWlzQk5NOXdtK2IvUVRKYlBaZ3VM?= =?utf-8?B?T1hPbXZkcDYzVWhJNGxVQ2c3ZFM3bUFOb0FiVVQ5emxuUTlZaFNMNC8rRlVW?= =?utf-8?B?MDF2eUJtVTR4SnpDVnI1UWEzWVBZZlhQMThINjVnMko5eGxKeVdHZG0rUVcx?= =?utf-8?B?d2gxSUpQQ1NLQ1hpVU1wak5OVmQzUk5sN253Z3hlVUVOSU51dks1R0xTTy9q?= =?utf-8?B?cVZmMy93ZHhGZ2lLaXhIUFNsSUlYZzJneFB3dFdiQWU1TnNCaXNSUWtzVjBp?= =?utf-8?B?cTBzRmVyZHRMRHNmRDhRVFV0VTcreXlkYjZoRHgyOWR0ZmVxVjNrcTh2L2tM?= =?utf-8?B?QmJlK3pDZDVCcHNKRTZjNlVac09LRDIyLzRQai9SMFpCa1Qxd1V0TEI3M3Va?= =?utf-8?B?bTJnYUFlY3lKZlNYZjkyRzFibGVONzRtdlNoOWxSQUVMSGVSYVN4V1RYOGVV?= =?utf-8?B?Ym5jRGt3UFlWTjVIeWloQk16aGw5UTBBdTIrQlFQODZRVUlGODBOYWVpWWZ2?= =?utf-8?B?VU94aFNuaVFGQlloWit2clVXLzhxVWIva1RreVZkZU9rZGZja0JjazlvSUtU?= =?utf-8?B?TTNPelBORmF1L0x5QTZIbjU2bE4xSXNiTDBBNGdkcTk0ZDh6UCs0RnB1RDQ0?= =?utf-8?B?ZGU5UXFZci9LeDlDcElZU3d6OTY2Vi9jRWd2RkRNYlF4dEpjS3c4ei92Q3VT?= =?utf-8?B?dy91UGtsK3pWT095Z2xUYkFXM3hBN1N4S0I4bE81VEJpVXJBcGxiMXJJUVU3?= =?utf-8?B?ZEZRLzBwOGRsSjB4eTlwL3FkWW1VWTNFYWI2YlcwVFZpSmlEbURGQjdzTGlM?= =?utf-8?B?KzAvVGtqQi9HNTNIZkcvTnIwVXFMSnpZaWU3cXNncUdMSWtUUkU5Q1R1VjNi?= =?utf-8?B?UWUvNmk3WjNVbUpyLzZKbFFQZzJQUjJpemFGQi8zSmhGWVRzQi9JNEl4TzFG?= =?utf-8?B?UjU2REluZVdWZWxEcDl3ZkRXenFzamVGcEZSTTY3cnV2d1F3WnpSR0lMVGpl?= =?utf-8?B?ZkVxRUhKSWh6eGVZZk00WnpWS2p5bGVpc240Mk1tWmVpRExuaGdtZE5Tam5v?= =?utf-8?B?amlaUVUzb29IRjNxZzNOMDAyTEtSVm8vbm41Qi9NOHFVdzY1NktDRGZvY29m?= =?utf-8?B?WEU3V3h6L2ltRTVUMlFPRFJ2anNFMlZqb3JkNE9aTVBFR1VqOC9zdjE4MmlV?= =?utf-8?B?NHY4RzE2VnZxdWlyV3NZRENjclIvVkgzeHlKYzZCV1M3VTA2V3NGRTEvQlZk?= =?utf-8?B?b3VCN2hZajh6MzVSOHVDKzhFTlBRN2hSYzJtUTBBRVFrN2k1R1RwTzlWWTVz?= =?utf-8?B?OWtBdHhrTTJjSHhDWjNLYjYzZ0d6MkdlelUrWDNlSkpKU1N6OWs0NUlLd0FH?= =?utf-8?B?N2VvQjZodFlIMWR1UHAzNUdmMDhIc2xFWnR3TVc1eHJkeUltemQ4ZFRRamJZ?= =?utf-8?B?MmhZM1BpdStla2p4Z2VDRWduNWlZV1dlNjFNb05KREs2NEZPOXVlL25IRk03?= =?utf-8?B?cXN5dTQ4K2tzZVBkTmFZMElrZDZBPT0=?= X-OriginatorOrg: auckland.ac.nz X-MS-Exchange-CrossTenant-Network-Message-Id: 03b6062a-62d1-43ef-9af4-08db119a6c7e X-MS-Exchange-CrossTenant-AuthSource: SY4PR01MB6979.ausprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Feb 2023 10:25:14.7192 (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: qnpjpJAdEAPl5YCIju70fiSJ8M8otxXyAYH+zyKqcO/2vrWjS5UPVX73lZtOxeoAsOsqJDAD432pZj6unU5ong1tXtN2XMxvJQ0jJLEprrI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ME3PR01MB7243 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: auckland.ac.nz Content-Type: multipart/alternative; boundary="------------M30rOst6G4mVPADYMtiN2Yx5" Content-Language: en-US Subject: Re: [Starlink] Starlink power use & satellite tracking 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: Sat, 18 Feb 2023 10:25:22 -0000 --------------M30rOst6G4mVPADYMtiN2Yx5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable I'd expect higher saturation to be associated with the use of fewer=20 satellites per user terminal, and therefore lower power use. Similarly, I'd expect proximity to gateways to be associated with higher=20 power use. What leads me to this impression? Essentially, inter-satellite linking isn't yet in widespread use for=20 Starlink, so most users at this point still use a bent-pipe arrangement=20 terminal<->satellite<->gateway<->Internet. This requires the satellite to be in view of both terminal and gateway.=20 There is, however, no reason why a user's packets could not travel via a=20 diversity of satellites. The only requirement for this arrangement is=20 that the satellites used must be in the intersection of the set of=20 satellites that the terminal can see and the set of satellites that the=20 gateway can see. What makes me think that this is actually happening? I'm in a low=20 saturation cell close to multiple gateways and partial obstruction of=20 the southern sky (which dishy uses in the southern hemisphere). So=20 whatever satellite my dishy sees, the gateways also see (more or less),=20 but the number of satellites I see is constrained by the partial=20 obstruction, so jumps up and down over short periods of time as the=20 satellites move in and out of view for me. When I look at achievable rates with the likes of speedtest.net then I=20 see huge jumps over relatively short periods of time. 20-30 Mb/s down=20 one moment, 160+ Mb/s in the next run. This is exactly what I'd expect=20 if dishy moves from a set of satellites with plenty of competition from=20 neighbouring rural regions (e.g., satellites south-east of Auckland) to=20 a larger set predominantly over the Tasman Sea, where there are no=20 users. I'm simplifying here. So if you happen to be a nerd in a fibre-connected and -penetrated city=20 surrounded by gateways, you should see higher power use as Starlink=20 wants you to have the maximum rate possible and will let you access=20 whichever birds are available during the current time period. If you're=20 in the wap-waps with your nearest gateway 100's of kilometres away (or=20 miles for youse Americans and Brits, we're talking ballpark here ;-)),=20 then the number of satellites you see that can relay to gateways for you=20 should be smaller on average. You would be facing stiff competition for=20 their capacity from your neighbours down the road. That would give you=20 less chance to transmit, and hence lower power use. Note: A mitigating=20 factor here could also be that the beams you need to communicate with=20 these relaying satellites from your dishy might be further off bore than=20 in the former case, which would require a little extra power to make up=20 for longer path and lower dishy aperture. Hope that makes sense? On 18/02/2023 4:43 am, Michael Richardson wrote: > > Ulrich Speidel via Starlink wrote: > > * Whether you consider your cell Starlink virgin territory or close to > > subscriber saturation (https://www.starlink.com/map=20 > =20 > might help > > determine that - if it's light blue, it's likely the former, if it's > > "waitlist" blue but surrounded by light blue areas, or rural and > > What's the expected corrolation? > Higher saturation =3D> higher current? Or the opposite? > --=20 **************************************************************** Dr. Ulrich Speidel School of Computer Science Room 303S.594 (City Campus) The University of Auckland u.speidel@auckland.ac.nz =20 http://www.cs.auckland.ac.nz/~ulrich/ **************************************************************** --------------M30rOst6G4mVPADYMtiN2Yx5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I'd expect higher saturation to be associated with the use of fewer satellites per user terminal, and therefore lower power use.

Similarly, I'd expect proximity to gateways to be associated with higher power use.

What leads me to this impression?

Essentially, inter-satellite linking isn't yet in widespread use for Starlink, so most users at this point still use a bent-pipe arrangement terminal<->satellite<->gateway<->Internet.

This requires the satellite to be in view of both terminal and gateway. There is, however, no reason why a user's packets could not travel via a diversity of satellites. The only requirement for this arrangement is that the satellites used must be in the intersection of the set of satellites that the terminal can see and the set of satellites that the gateway can see.

What makes me think that this is actually happening? I'm in a low saturation cell close to multiple gateways and partial obstruction of the southern sky (which dishy uses in the southern hemisphere). So whatever satellite my dishy sees, the gateways also see (more or less), but the number of satellites I see is constrained by the partial obstruction, so jumps up and down over short periods of time as the satellites move in and out of view for me.

When I look at achievable rates with the likes of speedtest.net then I see huge jumps over relatively short periods of time. 20-30 Mb/s down one moment, 160+ Mb/s in the next run. This is exactly what I'd expect if dishy moves from a set of satellites with plenty of competition from neighbouring rural regions (e.g., satellites south-east of Auckland) to a larger set predominantly over the Tasman Sea, where there are no users. I'm simplifying here.

So if you happen to be a nerd in a fibre-connected and -penetrated city surrounded by gateways, you should see higher power use as Starlink wants you to have the maximum rate possible and will let you access whichever birds are available during the current time period. If you're in the wap-waps with your nearest gateway 100's of kilometres away (or miles for youse Americans and Brits, we're talking ballpark here ;-)), then the number of satellites you see that can relay to gateways for you should be smaller on average. You would be facing stiff competition for their capacity from your neighbours down the road. That would give you less chance to transmit, and hence lower power use. Note: A mitigating factor here could also be that the beams you need to communicate with these relaying satellites from your dishy might be further off bore than in the former case, which would require a little extra power to make up for longer path and lower dishy aperture.

Hope that makes sense?

On 18/02/2023 4:43 am, Michael Richardson wrote:
=20
Ulrich Speidel via Starlink <starlink@lists.bufferbloat.n= et> wrote:
> * Whether you consider your cell Starlink virgin territory or close to
> subscriber saturation (https://www.starlink.com/map might help
> determine that - if it's light blue, it's likely the former, if it's
> "waitlist" blue but surrounded by light blue areas, or= rural and

What's the expected corrolation?
Higher saturation =3D> higher current? Or the opposite?

--=20
****************************************************************
Dr. Ulrich Speidel

School of Computer Science

Room 303S.594 (City Campus)

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