bwlimit
Added annex.bwlimit and remote.name.annex-bwlimit config that works for git
remotes and many but not all special remotes.
This nearly works, at least for a git remote on the same disk. With it set
to 100kb/1s, the meter displays an actual bandwidth of 128 kb/s, with
occasional spikes to 160 kb/s. So it needs to delay just a bit longer...
I'm unsure why.
However, at the beginning a lot of data flows before it determines the
right bandwidth limit. A granularity of less than 1s would probably improve
that.
And, I don't know yet if it makes sense to have it be 100ks/1s rather than
100kb/s. Is there a situation where the user would want a larger
granularity? Does granulatity need to be configurable at all? I only used that
format for the config really in order to reuse an existing parser.
This can't support for external special remotes, or for ones that
themselves shell out to an external command. (Well, it could, but it
would involve pausing and resuming the child process tree, which seems
very hard to implement and very strange besides.) There could also be some
built-in special remotes that it still doesn't work for, due to them not
having a progress meter whose displays blocks the bandwidth using thread.
But I don't think there are actually any that run a separate thread for
downloads than the thread that displays the progress meter.
Sponsored-by: Graham Spencer on Patreon
2021-09-21 20:58:02 +00:00
|
|
|
{- types for stall detection and banwdith rates
|
2020-12-08 19:22:18 +00:00
|
|
|
-
|
2024-01-19 19:14:26 +00:00
|
|
|
- Copyright 2020-2024 Joey Hess <id@joeyh.name>
|
2020-12-08 19:22:18 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
|
|
|
module Types.StallDetection where
|
|
|
|
|
|
|
|
import Utility.DataUnits
|
|
|
|
import Utility.HumanTime
|
|
|
|
import Utility.Misc
|
2021-02-03 17:19:47 +00:00
|
|
|
import Git.Config
|
2020-12-08 19:22:18 +00:00
|
|
|
|
2021-02-03 17:19:47 +00:00
|
|
|
data StallDetection
|
bwlimit
Added annex.bwlimit and remote.name.annex-bwlimit config that works for git
remotes and many but not all special remotes.
This nearly works, at least for a git remote on the same disk. With it set
to 100kb/1s, the meter displays an actual bandwidth of 128 kb/s, with
occasional spikes to 160 kb/s. So it needs to delay just a bit longer...
I'm unsure why.
However, at the beginning a lot of data flows before it determines the
right bandwidth limit. A granularity of less than 1s would probably improve
that.
And, I don't know yet if it makes sense to have it be 100ks/1s rather than
100kb/s. Is there a situation where the user would want a larger
granularity? Does granulatity need to be configurable at all? I only used that
format for the config really in order to reuse an existing parser.
This can't support for external special remotes, or for ones that
themselves shell out to an external command. (Well, it could, but it
would involve pausing and resuming the child process tree, which seems
very hard to implement and very strange besides.) There could also be some
built-in special remotes that it still doesn't work for, due to them not
having a progress meter whose displays blocks the bandwidth using thread.
But I don't think there are actually any that run a separate thread for
downloads than the thread that displays the progress meter.
Sponsored-by: Graham Spencer on Patreon
2021-09-21 20:58:02 +00:00
|
|
|
= StallDetection BwRate
|
2021-02-03 17:19:47 +00:00
|
|
|
-- ^ Unless the given number of bytes have been sent over the given
|
|
|
|
-- amount of time, there's a stall.
|
|
|
|
| ProbeStallDetection
|
|
|
|
-- ^ Used when unsure how frequently transfer progress is updated,
|
|
|
|
-- or how fast data can be sent.
|
2021-02-03 19:35:32 +00:00
|
|
|
| StallDetectionDisabled
|
2020-12-08 19:22:18 +00:00
|
|
|
deriving (Show)
|
|
|
|
|
bwlimit
Added annex.bwlimit and remote.name.annex-bwlimit config that works for git
remotes and many but not all special remotes.
This nearly works, at least for a git remote on the same disk. With it set
to 100kb/1s, the meter displays an actual bandwidth of 128 kb/s, with
occasional spikes to 160 kb/s. So it needs to delay just a bit longer...
I'm unsure why.
However, at the beginning a lot of data flows before it determines the
right bandwidth limit. A granularity of less than 1s would probably improve
that.
And, I don't know yet if it makes sense to have it be 100ks/1s rather than
100kb/s. Is there a situation where the user would want a larger
granularity? Does granulatity need to be configurable at all? I only used that
format for the config really in order to reuse an existing parser.
This can't support for external special remotes, or for ones that
themselves shell out to an external command. (Well, it could, but it
would involve pausing and resuming the child process tree, which seems
very hard to implement and very strange besides.) There could also be some
built-in special remotes that it still doesn't work for, due to them not
having a progress meter whose displays blocks the bandwidth using thread.
But I don't think there are actually any that run a separate thread for
downloads than the thread that displays the progress meter.
Sponsored-by: Graham Spencer on Patreon
2021-09-21 20:58:02 +00:00
|
|
|
data BwRate = BwRate ByteSize Duration
|
|
|
|
deriving (Show)
|
|
|
|
|
2020-12-08 19:22:18 +00:00
|
|
|
-- Parse eg, "0KiB/60s"
|
2021-02-03 17:19:47 +00:00
|
|
|
--
|
2024-04-06 13:50:58 +00:00
|
|
|
-- Also, it can be set to "true" (or other git config equivalents)
|
2021-02-03 17:19:47 +00:00
|
|
|
-- to enable ProbeStallDetection.
|
2024-04-06 13:50:58 +00:00
|
|
|
-- And "false" (and other git config equivalents) explicitly
|
2021-02-03 17:19:47 +00:00
|
|
|
-- disable stall detection.
|
bwlimit
Added annex.bwlimit and remote.name.annex-bwlimit config that works for git
remotes and many but not all special remotes.
This nearly works, at least for a git remote on the same disk. With it set
to 100kb/1s, the meter displays an actual bandwidth of 128 kb/s, with
occasional spikes to 160 kb/s. So it needs to delay just a bit longer...
I'm unsure why.
However, at the beginning a lot of data flows before it determines the
right bandwidth limit. A granularity of less than 1s would probably improve
that.
And, I don't know yet if it makes sense to have it be 100ks/1s rather than
100kb/s. Is there a situation where the user would want a larger
granularity? Does granulatity need to be configurable at all? I only used that
format for the config really in order to reuse an existing parser.
This can't support for external special remotes, or for ones that
themselves shell out to an external command. (Well, it could, but it
would involve pausing and resuming the child process tree, which seems
very hard to implement and very strange besides.) There could also be some
built-in special remotes that it still doesn't work for, due to them not
having a progress meter whose displays blocks the bandwidth using thread.
But I don't think there are actually any that run a separate thread for
downloads than the thread that displays the progress meter.
Sponsored-by: Graham Spencer on Patreon
2021-09-21 20:58:02 +00:00
|
|
|
parseStallDetection :: String -> Either String StallDetection
|
2021-02-03 17:19:47 +00:00
|
|
|
parseStallDetection s = case isTrueFalse s of
|
|
|
|
Nothing -> do
|
bwlimit
Added annex.bwlimit and remote.name.annex-bwlimit config that works for git
remotes and many but not all special remotes.
This nearly works, at least for a git remote on the same disk. With it set
to 100kb/1s, the meter displays an actual bandwidth of 128 kb/s, with
occasional spikes to 160 kb/s. So it needs to delay just a bit longer...
I'm unsure why.
However, at the beginning a lot of data flows before it determines the
right bandwidth limit. A granularity of less than 1s would probably improve
that.
And, I don't know yet if it makes sense to have it be 100ks/1s rather than
100kb/s. Is there a situation where the user would want a larger
granularity? Does granulatity need to be configurable at all? I only used that
format for the config really in order to reuse an existing parser.
This can't support for external special remotes, or for ones that
themselves shell out to an external command. (Well, it could, but it
would involve pausing and resuming the child process tree, which seems
very hard to implement and very strange besides.) There could also be some
built-in special remotes that it still doesn't work for, due to them not
having a progress meter whose displays blocks the bandwidth using thread.
But I don't think there are actually any that run a separate thread for
downloads than the thread that displays the progress meter.
Sponsored-by: Graham Spencer on Patreon
2021-09-21 20:58:02 +00:00
|
|
|
v <- parseBwRate s
|
|
|
|
Right (StallDetection v)
|
|
|
|
Just True -> Right ProbeStallDetection
|
|
|
|
Just False -> Right StallDetectionDisabled
|
|
|
|
|
2024-01-19 19:14:26 +00:00
|
|
|
readStallDetection :: String -> Maybe StallDetection
|
|
|
|
readStallDetection = either (const Nothing) Just . parseStallDetection
|
|
|
|
|
bwlimit
Added annex.bwlimit and remote.name.annex-bwlimit config that works for git
remotes and many but not all special remotes.
This nearly works, at least for a git remote on the same disk. With it set
to 100kb/1s, the meter displays an actual bandwidth of 128 kb/s, with
occasional spikes to 160 kb/s. So it needs to delay just a bit longer...
I'm unsure why.
However, at the beginning a lot of data flows before it determines the
right bandwidth limit. A granularity of less than 1s would probably improve
that.
And, I don't know yet if it makes sense to have it be 100ks/1s rather than
100kb/s. Is there a situation where the user would want a larger
granularity? Does granulatity need to be configurable at all? I only used that
format for the config really in order to reuse an existing parser.
This can't support for external special remotes, or for ones that
themselves shell out to an external command. (Well, it could, but it
would involve pausing and resuming the child process tree, which seems
very hard to implement and very strange besides.) There could also be some
built-in special remotes that it still doesn't work for, due to them not
having a progress meter whose displays blocks the bandwidth using thread.
But I don't think there are actually any that run a separate thread for
downloads than the thread that displays the progress meter.
Sponsored-by: Graham Spencer on Patreon
2021-09-21 20:58:02 +00:00
|
|
|
parseBwRate :: String -> Either String BwRate
|
|
|
|
parseBwRate s = do
|
|
|
|
let (bs, ds) = separate (== '/') s
|
|
|
|
b <- maybe
|
|
|
|
(Left $ "Unable to parse bandwidth amount " ++ bs)
|
|
|
|
Right
|
|
|
|
(readSize dataUnits bs)
|
|
|
|
d <- parseDuration ds
|
|
|
|
Right (BwRate b d)
|
2024-01-19 19:14:26 +00:00
|
|
|
|
|
|
|
readBwRatePerSecond :: String -> Maybe BwRate
|
|
|
|
readBwRatePerSecond s = do
|
|
|
|
sz <- readSize dataUnits s
|
|
|
|
return (BwRate sz (Duration 1))
|