text:
\section{Introduction}

The rapid growth in the number of blockchain protocols in the past few years has been boosted by the interest in crypto-currencies, decentralized finance, and identity systems. The solutions are mostly empirically driven, with direct economic incentives stimulating engineering experiments. To date, there are more than 700 different blockchain and distributed ledger platforms offering native digital assets and products
Many of these solutions deploy original families of consensus protocols or significant modifications of popular protocols, with variations in scalability, performance, and decentralization guarantees. These developments outpace systematization and research on inherent trade-offs of different design choices~\cite{fan2020performance}.

The absence of benchmarking solutions for comprehensive comparative analysis of various protocols is a particularly problematic omission, given the cumulative marketcap of 1,468 trillion \$ for these projects. More fundamentally, this systematization gap hampers our ability to tackle the increasing complexity of blockchain systems and make conscious design choices in blockchain engineering.
Developers of these protocols often provide performance metrics of blockchain solutions as declarative whitepapers that do not pass the standards of peer review and reproducibility, calling into question the reliability and objectivity of these measurements. For instance, it is a common practice to provide performance metrics of an isolated component and report them as a system-wide performance metric~\cite{rocket2019scalable, lokhava2019fast, cao2020performance}. This practice often leads to false impressions of the end-to-end system performance.

Few available benchmarking solutions, such as Blockbench~\cite{dinh2017blockbench} and Hyperledger Caliper~\cite{caliper} focus on narrow sets of permissioned consensus protocols or DAG-based protocols as DAGBENCH~\cite{dong2019dagbench}. There is also a noticeable deficit of academic research in macro benchmarks for blockchain systems. Existing studies are rather limited in scope either focusing on specific protocols such as Hyperledger~\cite{sukhwani_2018, kuzlu_2019} or Ripple~\cite{touloupou_2021}, or reusing Hyperldeger Caliper~\cite{dabbagh_2020} and Blockbench~\cite{dinh2017blockbench}. BCTMark is one of the few comparative benchmark studies which compares three different protocols, including permissionless Ethereum blockchain~\cite{saingre2020bctmark}. The authors in this study highlight the necessity to extend the comparison set and include more metrics such as partition tolerance. The most recent systematic survey on performance evaluation of blockchain systems demonstrates that available comparative studies are rather limited in scope both in terms of compared systems and depth of analysis, focusing on isolated layers of blockchain systems~\cite{fan2020performance}. To address this research gap, we design a benchmark that is comprehensive in scope, allowing us to stress-test the system under different network conditions.

\begin{figure*}[t]
	\center
	\includegraphics[width=0.88\linewidth]{assets/bgm}
	\caption{Our abstraction model of blockchain system as a transaction fabric, comprising four stages. The dotted line highlights the focus of most whitepaper benchmarks.}
	\label{fig:blockchain_model}
\end{figure*}

We introduce \emph{Gromit}, a generic benchmarking framework that allows a performance evaluation of \emph{any} blockchain solution.
Gromit treats each system under test as a transaction fabric, which means a transaction processing system where a group of peers continuously reach a consensus on transactions submitted by clients. Gromit analyses performance metrics related to transactional data, specifically throughput and latency.
As we will show, this data alone can reveal the limitations of various aspects of the system.

We show the applicability of Gromit{} and conduct the \emph{largest blockchain benchmarking study to date}.
Our benchmark involves seven major blockchain solutions with different consensus algorithms. We determine the peak performance of these blockchain systems for different numbers of peers and without any modifications to the source code.
A key finding is that the performance for most evaluated blockchain systems \emph{degrades} when the number of peers increases.
We also reveal the effect of network delays and an increase in system load on the distribution of end-to-end transaction latencies, yielding valuable insights into the real-life bottlenecks of underlying consensus mechanisms. While most performance bottleneck research focuses on the consensus layer, a system-wide stress test can reveal bottlenecks in other layers, e.g., in the persistence layer.

The contribution of this work is two-fold:
\begin{enumerate}
	\item We design and implement \emph{Gromit}, a benchmarking framework that enables an analysis of \emph{any} blockchain system (Section~\ref{sec:Prickle_architecture}).
	\item We conduct \emph{the largest blockchain benchmark to date}, measuring the performance of seven prominent blockchain systems (Section~\ref{sec:evaluation}).
\end{enumerate}

\section{Blockchain as a Transaction Fabric}
\label{sec:blockchain_as_tx_fabric}

In this work, we view a blockchain system as a \emph{transaction fabric}.
Figure~\ref{fig:blockchain_model} visualizes this abstraction model, which illustrates a typical transaction life cycle.

In our model, we distinguish between clients and peers. Clients are instances that create transactions and send them to peers. An example of a client is a light wallet or lightweight nodes in a Bitcoin network. Peers in our model are responsible for processing and validating transactions in a shared, decentralized network. Thus, we call them \emph{validator peers}. In some blockchain systems, they are also referred to as miners.

\subsection{Transaction Life Cycle Model}

\subsubsection{Transaction Creation}
A \textit{transaction} contains logic that modifies the system state, e.g., by transferring an asset to another account. Each transaction is cryptographically signed with the private key of the issuing client to ensure authenticity.
Blockchain solutions usually provide \textit{Wallet} API's for clients to submit their transactions, e.g., with an RPC endpoint or REST endpoint.

\subsubsection{Transaction Sharing}
Blockchain systems employ complex transaction sharing mechanisms. Permissionless blockchains typically use a global gossip protocol to share transactions over a structured or unstructured overlay. Permissoned blockchains are deployed in a more controlled network environment and, as a result, might share transactions using a broadcast algorithm.

The transactions are stored in a datastore, often called a transaction pool (\textit{TxPool}). The transaction pool is a temporary store used to queue or preprocess transactions before the network validates them.

\begin{figure*}[t]
	\centering
	\includegraphics[width=0.80\linewidth]{assets/grom_arch.pdf}
	\caption{Architectural overview and process flow of Gromit, our benchmarking framework for blockchain systems.}
	\label{fig:Prickle_architecture}
\end{figure*}

\subsubsection{Transaction Settlement}
A consensus algorithm is a crucial part of the blockchain system as a mechanism for achieving security and liveness\cite{bano2019sok}.
The intermediate outcome of the consensus process in blockchain systems is a set of valid transactions. Valid transactions are stored in a tamper-proof distributed ledger, a replicated data structure maintained by validators. The system discards invalid transactions.

Blockchain solutions typically bundle valid transactions in \textit{blocks}, interlinked in a hash chain, and stored in a local database (\textit{Block DB}).
Each block in a hash chain contains the cryptographic hash of the previous block, making illegitimate modifications of the chain detectable. Some blockchain-like systems adopt a different organization of the distributed ledger, e.g., by maintaining a Directed Acyclic Graph (DAG)~\cite{dong2019dagbench}.

\subsubsection{Transaction Status Response}
After the transaction is settled the client waits for a transaction approval (or rejection), received from validator peers.
Some blockchains also include a \textit{proof} in the response that proves that a transaction is finalized.

\subsection{Transaction Performance Indicators}

Our approach is to analyze the performance of current blockchain solutions through \emph{transaction benchmarking}.
The speed at which a blockchain system processes transactions is a defining metric for blockchains.
High transaction latencies directly impact end-users experience, e.g., the relatively high finalization times of Bitcoin transactions (10 minutes) make it unsuitable for interactive trade~\cite{bamert2013have}.
We include all stages of the transaction life cycle in our measurements, rather than focusing on the performance of the consensus layer only.

We obtain insights into the limitation of blockchain systems by measuring peak performance and associated transaction latencies.
We also measure performance under different network conditions, such as changes in the geographical distribution of the overlay network. Our experiments in Section~\ref{sec:evaluation} highlight that these metrics can reveal performance bottlenecks and act as a guideline for optimization efforts.

\section{Gromit: A Generic Framework for Blockchain Benchmarking}
\label{sec:Prickle_architecture}
We design and implement \emph{Gromit}, the first generic framework for blockchain benchmarking.
Gromit is designed for quick experiment iterations, utilizing a domain-specific language to devise experiments.
Our framework, implemented in Python, is based on the abstraction model discussed in Section~\ref{sec:blockchain_as_tx_fabric}.
To encourage the adoption of Gromit, its source code is published on Github.\footnote{See \url{https://github.com/grimadas/gromit}}
Gromit provides developers and researchers with the necessary tools to design benchmarks targeting blockchain performance.
Gromit spawns client and validator processes on remote servers and coordinates interactions between running processes, e.g., transaction issuing.

\subsection{Experiment Flow}
Figure~\ref{fig:Prickle_architecture} shows the architecture of the framework and the flow of an experiment.
This diagram is described next.

\textbf{Experiment Setup.}
Before an experiment starts, it spawns a dedicated process, called the \emph{orchestrator}, that setups the environment on remote servers and handles cross-server communication.
The orchestrator reads the configuration file associated with the experiment.
This file specifies the network addresses of remote servers and the number of clients and validators that should be started (step~\circled{1}).
The orchestrator then copies the source code and all necessary experiment files to the remote servers using \texttt{rsync}.
Next, the coordinator setups the environment on the specified servers over an SSH connection (step~\circled{2}).
This step includes the installation of required system packages and the generation of a genesis file.
This file describes the initial state of the blockchain system and can pre-load specific accounts with assets.
The orchestrator then starts a \emph{instance} for each client or validator on the remote server and assigns an identifier to each running instance.
The scenario manager, part of the logic of a Gromit instance, parses a provided scenario file and starts the experiment (step~\circled{3}).

\textbf{Scenario Files.}
A user describes the actions performed during an experiment with a \emph{scenario file}.
The scenario manager parses this file and schedules actions using the \texttt{asyncio} library.

\begin{lstlisting}[basicstyle=\small,caption={An example of a scenario file in Gromit, describing an experiment with 10 clients and validators.},captionpos=b,label={lst:scenario},frame=single]
@8   init_blockchain_config {1-10}
@12  start_validator {1-10}
@20  start_client {11-20}
@80  start_creating_transactions {11-20}
@100 stop
\end{lstlisting}

An example scenario file associated with a simple blockchain benchmark is given in listing~\ref{lst:scenario}.
Actions and their timestamps are explicitly denoted.
A user can schedule an action to execute on a subset of all validators.
Scenario files can be machine-generated and are a flexible approach to devising and conducting experiments.

\textbf{Experiment Runner.}
The experiment runner spawns validators and clients as a subprocess during each experiment run (step~\circled{4}).
Clients interact with validators through the exposed API endpoint.
We simulate a client in Gromit as a procedure that issues transactions.
During an experiment, Gromit instances can share data over a TCP connection through a message broker.
We use the message broker functionality to share the credentials of pre-defined blockchain accounts with clients.
Gromit contains tools to gracefully terminate a running experiment, e.g., when a particular condition is not met.

Gromit also provides utilities to track system resource usage.
Gromit instances monitor CPU, memory, disk, and network usage using the \texttt{procfs} library (step~\circled{5}).
These metrics allow us to estimate the system resource usage of blockchain systems.
Developers can easily extend Gromit to monitor specific metrics, for example, the number of inbound network messages for a particular blockchain system.

\textbf{Collecting Experiment Results.}
When the experiment ends, the orchestrator copies all generated artifacts from the remote nodes using \texttt{rsync} (step~\circled{6}).
These artifacts include the data generated by the blockchain systems and the data output by the Gromit instances, e.g., monitoring statistics.
This data is parsed by the orchestrator (step~\circled{7}) and generates human-readable graphs.
Finally, the data is stored in a database (step~\circled{8}) and is ready for analysis by the user (step~\circled{9}).

\subsection{Integrating Blockchain Systems into Gromit}
To show practicality of Gromit, we have integrated seven prominent blockchain systems into it. The integration requires no change in the source code of the blockchain systems. This allows to benchmark the blockchain system as close to the deployed systems as possible.

The design of Gromit is modular, and developers can implement \emph{modules} that enrich an experiment with more functionality, for example, bandwidth monitoring.
Integration of a blockchain system requires a developer to subclass the \texttt{BlockchainModule} and to implement the \texttt{init\_configuration}, \texttt{start\_validator}, \texttt{stop\_validator}, and \texttt{parse\_ledger} methods.
Gromit enables developers to specify custom network topologies to connect validators among each other.
We refer readers who wish to integrate a particular blockchain system to the Gromit documentation.

Besides supporting blockchain systems, Gromit has support for generic experiments with distributed systems. For example, we have used Gromit to conduct experiments with peer-to-peer protocols on custom infrastructure.

\subsection{Transaction Analysis}
A workload during a Gromit benchmark consists of transactions issued by one or more clients. All transactions can be submitted to one validator peer or can be evenly spread among the peers.
In line with related work, we mainly gauge blockchain performance using two metrics, transaction throughput, and transaction latency. Specifically, we consider the peak transaction \emph{throughput}, which is the maximum rate at which the system can process transactions before getting congested.
Second, we analyze the \emph{latency} of transactions, which is the time between submitting a transaction and its irreversible inclusion in the distributed ledger.

We store the timestamp at which a client has submitted the transaction to a validator to determine transaction latency.
However, determining the finalization time of transactions can be complicated since some blockchain systems do not expose granular, temporal information.
We use the following two approaches to determine the latency of individual transactions.
Our first approach is to inspect the resulting distributed ledger after all transactions have been issued (this logic should be part of the \texttt{parse\_ledger} method).
We then compute transaction latency based on timestamps included in ledger data elements (e.g., blocks). However, this approach is useful only if the blockchain system annotates data elements in the distributed ledger with a timestamp.
The second approach suggests clients periodically poll the blockchain system to determine if a transaction has been confirmed.

\section{Blockchain Consensus Model}
\label{sec:consensus_families}

Since the introduction of Bitcoin in 2008, there have been many proposals for new blockchains and consensus mechanisms.
Some proposals have materialized into operational systems, whereas other ones are only theoretically analyzed.
The proliferation of blockchain solutions makes it infeasible to conduct a benchmarking study with all available systems.

\begin{table*}
	\small
	\centering
	\begin{tabular}{ | p{3cm} | p{4.9cm} | p{3cm} | p{2.4cm} | p{2cm} |}
		\hline
		\textbf{Blockchain System} &
		\textbf{Consensus Model}
		& \textbf{Consensus Principle}
		& \textbf{Validator Group Formation}
		& \textbf{First commit (year)}
		\\ \hline
		Ethereum (v1.9.24)~\cite{wood2014ethereum} &
		Proof of Work (PoW)
		& Resource-based lottery & Resource mining &  2013
		\\ \hline
		Algorand (v2.3.0)~\cite{gilad2017algorand}  & Proof of Stake (PoS) &
		Random selection of leaders &
		Stake-based enrolment & 2019
		\\  \hline
		BitShares (v5.0.0)~\cite{schuh2017bitshares} & Delegated Proof of Stake (dPoS) & Rotating leader & Election by stakeholders & 2015
		\\ \hline
		Diem (v1.1.0)~\cite{libra2019} &
		Practical Byzantine Fault Tolerance (PBFT), based on HotStuff~\cite{yin2019hotstuff}
		&  Leader-based &
		Enrolment by an authority &  2019
		\\ \hline
		Stellar (v15.1.0)~\cite{lokhava2019fast} &
		Federated Byzantine Agreement (FBA)  & Quorum Intersection & User-defined quorums
		&  2014
		\\ \hline
		Hyperledger Fabric (v1.4.9)~\cite{androulaki2018hyperledger} &
		Crash-tolerant consensus (CFT), based on Raft~\cite{ongaro2014search} &
		Leader-based &
		Enrolment by an authority &  2016
		\\ \hline
		Avalanche (v1.1.1)~\cite{rocket2019scalable} &
		Meta-Stable Consensus (MSC) & Network subsampling & Stake-based enrolment &  2020\\ \hline
	\end{tabular}
	\caption{The seven selected blockchain systems and consensus models analysed in this work.} \label{tab:systems_comparison}
\end{table*}

Based on taxonomy of different consensus mechanisms used in blockchain systems~\cite{bano2019sok} we consider seven prominent consensus models and select a representative blockchain system for each consensus model.
Our selection process is based on the economic magnitude, adoption, maturity of the system, and the protocol's academic significance.
Table~\ref{tab:systems_comparison} lists the representative system for each considered consensus model. For each system, we also show the evaluated version of the software, the principle underpinning each consensus model, how the group of validators is formed, and the year in which the first software commit has been made (as an indicator of matureness).
We are aware of state-of-the-art blockchains that use techniques such as layer-one scaling to improve throughput, e.g., OmniLedger~\cite{kokoris2018omniledger} and RapidChain~\cite{zamani2018rapidchain}, or layer-two scaling solutions~\cite{gudgeon2020sok}.
However, the primary focus of our benchmarking study is on deployed layer-one blockchain systems.
We now elaborate on each consensus model and refer the reader to \cite{bano2019sok} for a more extensive overview of blockchain consensus models.

\textbf{Proof-of-Work (PoW)} is the oldest consensus mechanisms designed explicitly for blockchain systems.
PoW is used in blockchains such as Bitcoin~\cite{nakamoto2019bitcoin} and Ethereum~\cite{wood2014ethereum} and to date remains a standard approach to build open blockchain systems. PoW scales well in the number of participants: the Bitcoin network has over 11'000 operational miners.
However, PoW is known to consume large amounts of energy, and the achievable transaction throughput is theoretically limited to around 60 transactions per second~\cite{gervais2016security}.

\textbf{Proof-of-Stake (PoS)}, initially proposed by the Peercoin cryptocurrency~\cite{king2012peercoin}, is an alternative consensus mechanism that addresses the excessive resource usage by PoW. PoS is typically based on a random, periodic selection of a leader. This selection process is weighted by the participants' stake in the system, e.g., by the number of assets owned, or by the age of possessed assets. Algorand is one of the most prominent PoS-based blockchains and leverages Verifiable Random Functions (VRFs) for the leader election process~\cite{gilad2017algorand}.

\textbf{Delegated Proof-of-Stake (dPoS)} is a consensus mechanism where stakeholders elect a group of \emph{delegates} through voting.
Voting decision can, for example, be based on community engagement.
Since the set of validators participating in consensus remains relatively small compared to PoS-based solutions, dPoS-based consensus has in theory a better potential to scale.
BitShares is one of the most mature blockchains using dPoS consensus~\cite{schuh2017bitshares}.

\textbf{Practical Byzantine Fault Tolerance (PBFT)} is a consensus algorithm introduced in 1999~\cite{castro1999practical}.
PBFT is specifically designed for networks with static and pre-approved membership and has been revised for adoption in blockchain environments.
Recent advancements have resulted in HotStuff~\cite{yin2019hotstuff}, a consensus protocol based on PBFT that reduces communication overhead and increases throughput.
HotStuff is at the core of Diem, a permissioned distributed ledger maintained by a consortium led by Facebook~\cite{libra2019}.

\textbf{Federated BFT (FBFT)} is a consensus model that distinguishes itself from the approaches mentioned earlier by having validators explicitly specifying trust relations.
Stellar is one of the first systems to adopt FBFT consensus~\cite{lokhava2019fast}.
The Stellar Consensus Protocol (SCP) leverages a federated voting approach in which each validator votes on statements while ensuring that no two members of an overlapping quorum can confirm contradicting statements.

\textbf{Crash-tolerant Consensus (CFT)} is a consensus approach widely used to achieve fault tolerance, e.g., by Apache Kafka~\cite{kafka}. Unlike PBFT,
CFT is not resistant against arbitrary (Byzantine) behaviour but can withstand crash-stop failures of participants.
Notable algorithms achieving CFT are Paxos~\cite{lamport2001paxos} and Raft~\cite{ongaro2014search}.
Hyperledger Fabric, one of the most prominent industrial blockchains, is currently using Raft~\cite{androulaki2018hyperledger}.

\textbf{Metastable Consensus (MSC)} is a family of consensus algorithms that leverage network subsampling techniques to determine the validity of a transaction.
The idea is to repeatedly sample random validators in the network and to steer correct nodes to a common decision.
Avalanche is one of the most mature  blockchain solutions to leverage MSC consensus and maintains a DAG data structure to store transactions~\cite{rocket2019scalable}.

\begin{figure*}[t]
 \centering
 \begin{subfigure}{0.8\textwidth}
 \centering
		\includegraphics[width=0.8\linewidth]{assets/legend_2.pdf}
	\end{subfigure}
	\centering
	\begin{subfigure}{.45\textwidth}
	 \vspace{0.2mm}
		\includegraphics[width=\linewidth]{assets/max_throughput.pdf}
		\caption{Peak transaction throughput}
		\label{fig:scalability_throughput}
	\end{subfigure}%
	\begin{subfigure}{.45\textwidth}
 	\vspace{-0.1mm}
		\includegraphics[width=\linewidth]{assets/max_latency.pdf}
		\caption{Transaction latency}
		\label{fig:scalability_latency}
	\end{subfigure}
	\caption{The peak throughput and transaction latencies of evaluated blockchain systems with the number of validators.}
	\label{fig:scalability}

\end{figure*}

\section{Blockchain Performance Evaluation}
\label{sec:evaluation}
We conduct a diverse set of experiments with Gromit to reveal the performance characteristics and limitations of seven blockchain solutions.
To the best of our knowledge, We are the first to perform a large-scale performance benchmark of blockchain solutions.

Our experiments answer the following questions:
How does the increase in the number of validators affect the system performance?
What is the peak performance of each system under a heavy system load?
What is the impact of a network delay on systems' performance?
How consistent are our performance results compared to previously reported values?

Throughout the section we use two variables for our experiments: $n$ indicates the number of validators and $\lambda$ signifies the transaction throughput.

\subsection{Setup and Transaction Workload}

All experiments are conducted on four HPE DL385 Gen10 servers, located within the same data centre and inter-connected with 10GB Ethernet links.
Each server is equipped with 128 AMD EPYC 7452 CPUs, has 512GB of DDR4 memory, and runs Debian 10.
During our experiments, we deploy each blockchain system with its source code unmodified.
For each system, we use the default settings provided by the systems.
Each experiment starts with only the genesis block included in the blockchain.
We use a random network topology where each validator is connected to 10 other random validators.

We use Gromit to subject each system to a synthetic transaction workload, issued by up to 64 clients.
To ensure an equal load on each validator, a client submits transactions to the validator with ID $ i \equiv c\ (\mathrm{mod}\ n) $ where $ c $ is the ID of the client and $ n $ the total number of validators.
Each transaction is submitted to exactly one validator.
Transactions are submitted during a two-minute period, after which we wait an additional minute for all transaction to be finalized.

We use simple asset transfers as a performance baseline.
In our workload, a transaction issued by a client involves an asset transfer of a small, fixed amount to another account; the client counterparty is fixed throughout the experiment.
We ensure that each client has sufficient funds to spend during the experiment.
For Ethereum and Hyperledger Fabric, transactions involve the transfer of an ERC20 token.

\subsection{Determining Peak Transaction Throughput}
To determine peak transaction throughput, we gradually increase the system transaction rate in steps of 100 transactions per second (tx/s).
Based on the reported statistics by Gromit, we estimate the peak transaction load that each system is still able to process during a sustained period.
If the system has any unconfirmed transactions after our two-minute period, we consider the system as \enquote{saturated}.
We evaluate the peak throughput of each system with an increasing number of validators ($ n $).
We provide each system with an equal amount of resources and ensure that the resource usage of evaluated systems (CPU power, disk space, and memory) does not exceed the available resources.
Due to excessive resource usage of the Stellar software, we are only able to run Stellar with up to $64$ validators.
We run each experiment at least five times and average all results.
Appropriate graphs are annotated with 95\% confidence interval markers.
\\\
\\\
\textbf{Finding 1.}
\emph{Adding validators does not have a significant positive effect on the achievable peak transaction throughput of the evaluated systems.} \\

Figure~\ref{fig:scalability} shows the result of our scalability experiment as $ n $ grows, in terms of peak transaction throughput and transaction latency.
Figure~\ref{fig:scalability_throughput} shows the peak transaction throughput of evaluated systems (with a horizontal and vertical log-axis).
We notice that none of the evaluated systems can process over 1'000 tx/s with $ n = 128 $.
In general, the transaction throughput of most of the systems is capped between 500 and 1'500 tx/s.
Except for Ethereum, the peak transaction of all blockchains is \emph{decreasing} as $ n $ increases. Specifically,
Hyperledger Fabric shows a severe degradation in performance when $ n > 8 $, and is just capable of processing 2 to 4 tx/s with $ n = 128 $.
We believe that this is caused by the underlying consensus model of Hyperledger Fabric, Raft, which does not scale well with the number of validators~\cite{ongaro2014search}.
Of all systems, Ethereum has the lowest transaction throughput (around 10-20 tx/s), yet manages to keep stable throughput with the increase in the number of validators.
Peak throughput of Avalanche increases up to $n=64$, but then degrades for $n=128$.

\noindent \\ \textbf{Finding 2.}
\emph{For Avalanche, BitShares and Hyperledger Fabric, we observe significant discrepancies between the peak throughput found by us and previously reported values.} \\

\begin{figure*}[t]
	\centering
	\includegraphics[width=.8\linewidth]{assets/latency_violin.pdf}
	\caption{The distribution of transaction latencies for systems, under peak load ($ \lambda $ tx/s) and moderate load ($ \frac{\lambda}{2} $ tx/s) ($n = 64$).}
	\label{fig:latency_load}
\end{figure*}

The previous experiment estimates the peak throughput of blockchain systems, without modification to the source code and under default settings.
We now compare the performance results with values reported by other literature.
The performance, i.e. peak throughput, is typically determined through an evaluation by system developers themselves.
For Stellar, we could not find reliable benchmarking results, making this work the first benchmarking study of Stellar.
We are interested to see if there are significant inconsistencies with performance metrics reported by these studies.

Our performance results are comparable with results reported for Ethereum~(4-40 tx/s~\cite{pongnumkul2017performance}), Algorand~(880 tx/s~\cite{gilad2017algorand}) and Diem~(200-1'000 tx/s~\cite{zhang2019performance}).
However, we notice that previously reported values for some systems are significantly higher than our findings, specifically for Avalanche~(7'000 tx/s, 26x higher~\cite{rocket2019scalable}), BitShares~(3'300 tx/s, 3x higher~\cite{bitsharesperformance}) and Hyperledger Fabric~(3'500 tx/s, 2 times higher~\cite{androulaki2018hyperledger}).
For each system, we now explain these inconsistencies with additional experiments and analysis.

\textbf{Avalanche.}
The relative low throughput of Avalanche surprises us and warrants further performance analysis.
Since we noticed that each validator node is fully utilizing a CPU core, even with $ n = 4 $ and 32 tx/s, we perform a CPU analysis of deployed validators using the \texttt{pprof} profiler.
We find that around 60\% of CPU time is spent on hash computations using the \texttt{argon2} algorithm~\cite{biryukov2016argon2}.
This CPU consumption originates from the API provided by Avalanche validators.
Specifically, each validator maintains a keystore with credentials that is managed by end users; interactions with that keystore, e.g., accessing a private key, requires the user to include the password hash in the request.
Consequently, many parallel requests to the API by clients cause severe performance degradations.

To analyse the impact of password hashing, we recompile Avalanche with this hash verification disabled and re-run our experiment.
We do not observe a significant increase in transaction throughput.
However, this reveals another performance bottleneck, originating from the verification of transactions, consuming around 90\% of CPU time.
Since Avalanche transactions are linked in a DAG structure, incoming transactions require the validation of parent transactions, which is a resource-intensive, recursive operation.
We believe this can be addressed with further engineering efforts, e.g., queueing the verification of transactions.

\textbf{BitShares.}
We further analyse the reported throughput of BitShares and found that the peak transaction throughput (3'300 tx/s) is not an accurate performance indicator since the sustained throughput throughout the experiment is only around 450 tx/s.
Specifically, the achievable throughput of the BitShares consensus algorithm seems to be predicated by the speed of the slowest consensus participants in terms of connectivity and CPU resources. When operating BitShares in a heterogeneous environment, this can result in significant deviations in transaction throughput.

\textbf{Hyperledger Fabric.}
We further analyse the results reported in the work of Androulaki et al.~\cite{androulaki2018hyperledger} and Blockbench~\cite{dinh2017blockbench}.
We find that their work evaluates an early implementation of Hyperledger Fabric using a different consensus model (Zookeeper or PBFT). As such, these results are not directly comparable.

We also present the following two reasons to explain the discrepancies in reported and observed throughput numbers:
\begin{enumerate}
	\item \emph{Experimental Software vs Production}. Many of the throughput numbers reported by system developers are extracted using a premature or even incomplete software implementation.
	As such, we argue that the values found by our experiments are a more accurate reflection of the achievable throughput in a production environment.
	Additionally, we noticed that some solutions (Diem and Stellar) have built-in measures that artificially lower the achievable throughput, likely to ensure safety properties or to prevent attacks in a production environment. A similar insights were observed in~\cite{chacko2021my}.
	\item \emph{Client-Validator Interaction}.
	In our experiments, clients submit transactions to the API exposed by the system, whereas other studies might directly inject transactions in the validator process.
	API-based interaction adds additional overhead as the request needs to be processed, and this approach therefore is likely to lower the peak throughput of the system.
	However, this approach resembles how users interact with validators when a blockchain system is Internet-deployed.
\end{enumerate}

\subsection{Transaction Latency}

\textbf{Finding 3.}
\emph{For all evaluated systems, the average transaction latency under peak load is largely independent of the number of validators.}\\

\begin{figure*}[t]
	\centering
	\includegraphics[width=0.9\linewidth]{assets/tx_latencies_with_network_delays.pdf}
	\caption{Transaction latencies without network modifications and in a geo-distributed setting ($ \lambda = 64 $ tx/s, $ n = 32 $). The transaction latencies of Ethereum are shown in the right plot.}
	\label{fig:latency_challege}
\end{figure*}

Figure~\ref{fig:scalability_latency} shows the average transaction latency under peak load, as $ n $ increases.
Except for Ethereum, the average transaction latency of evaluated systems is around or below ten seconds.
The variance between different runs is relatively low, except for Ethereum.
In general, the average transaction latency increases as the number of validators grows.
The consensus algorithm underlying BitShares, Algorand and Stellar progresses in five-second rounds, theoretically resulting in an average transaction latency of 2.5 seconds.
We see that the transaction latency of Algorand increases from 5 seconds for $ n = 4 $ to 15 seconds with $ n = 128 $, suggesting that consensus rounds take longer to complete.
For BitShares and Stellar, this increase is less pronounced.
\\\\
\textbf{Finding 4.}
\emph{The variance of transaction latencies for Algorand and Diem increases significantly under peak load, compared to a moderate load. However, the transaction latencies of BitShares and Ethereum are largerly indifferent towards the system load.}\\

We visualize the distribution of transaction latencies for each system to explore further the effects of increasing the system load on the transaction latency.
We consider both peak and moderate loads, the latter being defined as half the determined peak load.
Figure~\ref{fig:latency_load} shows this distribution in a violin plot.
We observe that Algorand, BitShares, Hyperledger Fabric, and Stellar transaction latencies are roughly uniformly distributed under moderate load.
These systems adopt a round-based consensus approach, with a target of around five seconds for Algorand, BitShares, and Stellar, and one second for Hyperledger Fabric.
For these systems, most transactions are usually confirmed within the current or next consensus round relative to transaction submission.
The distribution of transaction latencies transforms as the system is subjected to a peak load.
Figure~\ref{fig:latency_load} shows that the finalization of Algorand transactions is being deferred to later rounds: 6\% of Algorand transactions have a transaction latency above 20 seconds.
This effect is less pronounced for BitShares and Stellar.

Increasing the system load impacts the latency distribution of Diem transactions.
Further investigation reveals that the round duration in Diem adjusts to the system load.
As more validators join the network and as more transactions are submitted to Diem validators, the round duration increases to ensure transactions can be processed on time.
Nonetheless, 30\% of all issued transactions in Diem are confirmed only after 10 seconds under peak load, whereas the system can handle all submitted transactions within 7 seconds under moderate load.

\subsection{Impact of Network Delays}
\textbf{Finding 5.}
\emph{Adding network delays has a minimal effect on the transaction latencies of Algorand and Stellar. However, Avalanche and Diem are extremely sensitive to network delays.}\\

Finally, we modify the network settings using the \texttt{netem} Linux kernel module\footnote{TC documentation: \url{https://www.linux.org/docs/man8/tc-netem.html}} and measure the impact of a network delay on the transaction latency for integrated blockchain systems.
This experiment reveals how different blockchain systems are sensitive to deployment in geo-distributed settings. To replicate realistic network delays, we extract ping statistics for 32 cities worldwide from WonderNetwork~\cite{WonderNetwork} and assign each validator to a city in a round-robin fashion.

Figure~\ref{fig:latency_challege} shows the distribution of transaction latencies of systems deployed in one data center with unmodified network settings and when deployed with geo-distributed settings.
For each experiment run, we use 32 validators and fix the transaction load to 64 tx/s, which all evaluated systems can handle without congestion.
Except for Algorand and Stellar, network delays visibly impact transaction latencies.

The effect is the most pronounced for the permissoned systems Diem and Hyperledger Fabric. This suggests that these systems can only operate in controlled/closed network environments, as any change in the network significantly affects the performance. We also observe a significant impact of network conditions on Avalance. This is due to the poll-based nature of metastable consensus. The poll rounds are visible in Figure~\ref{fig:latency_challege}.

For BitShares, we observe that validators occasionally fail to produce a block with higher network latency. For Diem, consensus progress stales a few seconds after starting the experiment, and rounds are timing out without confirming any transaction, violating system liveness.

\subsection{Network and CPU Utilization}

\textbf{Finding 6.}
\emph{Algorand, Stellar, Diem show high network utilization under idle load. Ethereum, Stellar and Diem consume significant CPU resources under idle load.}\\

\begin{figure*}[t]
    \begin{subfigure}{\textwidth}
		\includegraphics[width=\linewidth]{assets/legend.pdf}
	\end{subfigure}
	\centering
	\begin{subfigure}{.48\textwidth}
	    \vspace{0mm}
		\includegraphics[width=0.9\linewidth]{assets/bandwidth_load.pdf}
		\caption{Network usage}
		\label{fig:bandwidth_load}
	\end{subfigure}%
	\begin{subfigure}{.48\textwidth}
	    \vspace{0mm}
		\includegraphics[width=0.8\linewidth]{assets/utime_load.pdf}
		\caption{CPU utilization}
		\label{fig:utime_load}
	\end{subfigure}
	\caption{The resource utilization of the evaluated systems with increase in transaction load ($n = 32$).}
	\label{fig:resources_under_load}
\end{figure*}

\begin{figure*}[t]
	\centering
	\begin{subfigure}{.48\textwidth}
		\vspace{-3mm}
		\includegraphics[width=0.9\linewidth]{assets/bandwidth_nodes.pdf}
		\caption{Network usage}
		\label{fig:scalability_resource_usage_bandwidth}
	\end{subfigure}%
	\begin{subfigure}{.48\textwidth}
		\vspace{-3mm}
		\includegraphics[width=0.9\linewidth]{assets/utime_nodes.pdf}
		\caption{CPU utilization}
		\label{fig:scalability_resource_usage_cpu}
	\end{subfigure}
	\caption{The network and CPU usage for evaluated systems, when increasing the number of validators ($\lambda = 32 $ tx/s).}
	\label{fig:scalability_resource_usage}
\end{figure*}

We track the total network usage (inbound and outbound traffic) and average CPU utilization for each system while increasing $ \lambda $ and fixing $ n $ to 32.
To obtain insights into the system under idle load, we also run blockchain systems with $ \lambda = $ 0 tx/s.
Figure~\ref{fig:bandwidth_load} shows that the network usage per validator quickly grows for Avalanche and Stellar as the transaction load increases.
For $ \lambda = 256 $ tx/s, both Avalanche and Stellar use over 800 MB of network traffic per validator process.
BitShares is the most network-efficient, using only 80 MB per validator for $ \lambda = 256 $ tx/s.
We also observe that Algorand, Diem, and Stellar show 10x to 100x more bandwidth consumption under no transaction load compared to other systems.

Figure~\ref{fig:utime_load} shows the average CPU utilization when increasing $ \lambda $.
The mining process of Ethereum is continuously utilizing a single CPU.
Under $ \lambda = 256 $ tx/s, BitShares and Hyperledger Fabric are the most CPU-efficient compared to other systems.
Our synthetic workload results are consistent with real-world observations of liveness issues for Avalanche and Stellar~\cite{ogrady_2021, mcsweeney_2021}.

Figure~\ref{fig:scalability_resource_usage_bandwidth} shows that Diem is using significant network resources for $ n = 4 $: 970 MB per validator process.
This number decreases quickly when $ n $ increases.
We explain this behavior by the self-adjusting round times of the Diem consensus mechanism: as $ n $ increases, rounds take longer to complete, lowering the bandwidth usage.
For Stellar, we see the opposite effect: network usage becomes significant for $ n = 128 $.
Although Stellar cannot process transactions for $ n=128 $, we report its resource usage nonetheless.
Inspection of Stellar logs reveals that validators lose track of consensus, clogging the network with resynchronization messages.

Figure~\ref{fig:scalability_resource_usage_cpu} shows how CPU utilization behaves when increasing $ n $.
BitShares is the most CPU-efficient for all evaluated values of $ n $.
The CPU load of validators decreases for Avalanche and Diem as $ n $ increases.
Since we fix the transaction load, adding more validators decreases the individual load.

\section{Related Work}
Blockchain benchmarking and its associated challenges has received attention from other researchers.
Fan et al. present an extensive survey outlining methods for evaluating blockchain performance~\cite{fan2020performance}.
The work of Wang and Ye describes benchmarking tools and consensus mechanisms and outlines techniques to improve the throughput of blockchains~\cite{wang2019performance}.
The authors of these studies summarize work on blockchain performance but do not conduct benchmarking studies themselves.

Popular blockchain benchmarking tools are Blockbench~\cite{dinh2017blockbench}, Hyperledger Caliper~\cite{caliper}, and DAGBench~\cite{dong2019dagbench}.
Blockbench, introduced in 2017, is the earliest benchmarking framework for blockchain and is specifically designed to evaluate permissioned blockchains~\cite{dinh2017blockbench}.
Blockbench measures the performance of components commonly found in blockchains, e.g., the transaction execution engine).
The authors of Blockbench evaluate the performance of Hyperledger Fabric, Ethereum, and Parity.
Hyperledger Caliper is a benchmarking tool for the performance evaluation of specific systems with a set of pre-defined use cases~\cite{caliper}.
Hyperledger Caliper primarily supports projects by the Hyperledger Foundation.
DAGBench is a benchmarking tool for DAG-based blockchains~\cite{dong2019dagbench}.
The authors evaluate three popular DAG-based blockchain implementations~\cite{pervez2018comparative}: IOTA, Nano, and Byteball.
However, DAGBench does not allow for a comparison of other blockchains. The authors of BCTMark~\cite{saingre2020bctmark}. present an Ethereum performance evaluation.

\section{Conclusion}
We have presented Gromit, a generic benchmarking framework for blockchain solutions.
By treating each blockchain system as a transaction fabric, our framework enables any blockchain system's integration, benchmarking, and performance analysis.
We leverage the functionalities of Gromit and conduct the largest blockchain benchmark to date, involving seven prominent blockchain systems.
Our main finding is that none of the evaluated solutions can handle beyond 1'000 transactions per second as the number of validators increases. Yet, they show relatively low transaction latencies on average.
We also find that synthetic workloads can provide accurate predictions of performance limitations, as our findings are consistent with real-world observations on performance incidents on Avalanche and Stellar networks.

\bibliographystyle{IEEEtran}

redpajama_set_name: RedPajamaArXiv


text:
Landscape Design Schools in Massachusetts
Massachusetts contains one school that offers landscape design programs. Springfield Technical Community College	has a total student population of 6,782 and is the 5155th	highest ranked school in America.
Landscape Design students from Massachusetts schools who go on to become landscape designers, landscape architects, landscapers, landscape supervisors, etc. have a good chance at finding employment. For example, there are 10,510 people working as designers alone in the US, and their average annual salary is $50,420. Also, Landscaping and groundskeeping workers make on average $25,340	per year and there are about 859,960	of them employed in the US today. In fact, in the Massachusetts alone, there are 18,960 employed landscaping and groundskeeping workers earning an average yearly salary of $31,030. Designers in this state earn $52,990/yr and there are 260 employed.
Also, within the landscape design schools in Massachusetts, the average student population is 2,580	and average student-to-faculty ratio is 14 to 1. Aside from landscape design, there are 5364 total degree (or certificate) programs in the state, with 4,075	people on average applying for a school. Undergraduate tuition costs are normally around $5,628, but can vary widely depending on the type of school.
Massachusetts Interesting Facts
552 original documents pertaining to the Salem witch trials of 1692 have been preserved and are still stored by the Peabody Essex Museum.
Boston built the first subway system in the United States in 1897.
Although over 30 communities in the colonies eventually renamed themselves to honor Benjamin Franklin. The Massachusetts Town of Franklin was the first and changed its name in 1778.
"Norfolk County is the birthplace of four United States presidents: John Adams, John Quincy Adams, John Fitzgerald Kennedy and George Herbert Walker Bush."
In Holyoke, William G. Morgan, created a new game called "Mintonette" in 1895. After a demonstration given at the YMCA in nearby Springfield, the name "Mintonette" was replaced with the now familiar name "Volleyball."
Top National Parks in Massachusetts:
Borderland State Park »
Massasoit State Park »
Ames Nowell State Park »
Leonard Bernstein »
Benjamin Franklin »
Jack Albertson »
Landscape Design Information
Salary Details for a Landscape Architect
Online Landscape Design Schools
Online Landscape Design Programs
Online Landscape Design Courses
Online Landscape Design Certifications
Related Subjects - Schools in or near Massachusetts
Landscape Design Schools in Boston
Landscape Design Schools in Worcester
Landscape Design Schools in Cambridge
Landscape Design Schools in Lowell
Landscape Design Schools in Brockton
Landscape Design Schools in New Bedford
Landscape Design Schools in Fall River
Landscape Design Schools in Somerville
Landscape Design Schools in Framingham
Landscape Design Schools in Waltham
Landscape Design Schools in Malden
Landscape Design Schools in Taunton
Landscape Design Schools in Brookline
Landscape Design Schools in Weymouth
Landscape Design Schools in Peabody
Landscape Design Schools in Chelsea
Landscape Design Schools in North Attleborough
Landscape Design Schools in Attleboro
Landscape Design Schools in Leominster
Landscape Design Schools in Billerica
Landscape Design Schools in Westfield
Landscape Design Schools in North Andover
Landscape Design Schools in Wellesley
Landscape Design Schools in Watertown
Landscape Design Schools in Northampton
Landscape Design Schools in Milton
Landscape Design Schools in Chestnut Hill
Landscape Design Schools in West Barnstable
Landscape Design Schools in Brighton
Landscape Design Schools in Fitchburg
Landscape Design Schools in Woburn
Landscape Design Schools in Needham
Landscape Design Schools in North Dartmouth
1 Armory Sq, Springfield, Massachusetts 01105-1296
Massachusetts contains one school that offers landscape design programs. Springfield Technical Community College has a total student population of 6,782 and is the 5155th	highest ranked school in America.
Cities in Massachusetts
States Near Massachusetts

redpajama_set_name: RedPajamaCommonCrawl


Full description of Lumosity – Brain Training .
To Download Lumosity – Brain Training For PC,users need to install an Android Emulator like Xeplayer.With Xeplayer,you can Download Lumosity – Brain Training for PC version on your Windows 7,8,10 and Laptop.
4.Install Lumosity – Brain Training for PC.Now you can play Lumosity – Brain Training on PC.Have fun!


text:
How cash crunch brought Greeks to their knees
by Ivana Kottasova @ivanakottasova July 8, 2015: 8:23 AM ET
Greek businesses struggle amid cash crunch
Traffic in Athens has been unusually good recently. Living under capital controls forces people to spend as little as they can. That means cutting out unnecessary journeys.
"It's noticeable. People don't drive any more. There's been almost no traffic," taxi driver Kostas Gevetos said. His business has slowed down in recent months, with many locals opting for cheaper public transportation.
Banks in Greece have been closed for over a week, as the government tries to keep the financial sector afloat. Greeks have drained tens of billions of euros from their accounts in recent months, fearing the consequences of economic collapse.
Gevetos' biggest worry is fuel. "All petrol in Greece is imported, and with the banks closed, how will we get it?," he said. "The government said we have enough for a month. But I don't know if I can believe it."
Taking taxis is out of the question for pensioner Eva Ferentinos. She has never counted money as carefully as she does now. When she went shopping in her neighborhood on Monday evening, she bought lettuce, two carrots, two bananas and some celery. She couldn't afford more. Her pension is 831 euros a month and she can only take out 50 euros at a time. "But I try not to spend it, because I will need it for the rent and electricity," she said.
Sotiris Flamouris' business has dropped 30% since the banks closed.
Opinion: Why "Grexit" would be good for Greece
The urge to save as much cash as possible is troubling Greek business owners who have seen fewer and fewer customers in the past few weeks. Bakery owner Sotiris Flamouris said business has been down 30% in the week since the government imposed capital controls.
Tobacconist Vaso Giannakopoulou has a similar experience. She's seen the number of customers drop by a third since the banks closed last week.
The Greek economy has shrunk by 25% in the last five years, according to IMF data, and one in five businesses has gone bust. Nearly 60 companies have closed each day this year, according to the Hellenic retail business association.
The cap on cash withdrawals has brought Giannakopoulou practical problems too. "The banks have now run out of 20 euro notes, so everyone comes with 50 euros, it's very difficult to get change," she said.
Greece in crisis: Compete coverage
Many ATMs in Athens have run out of 20 euro notes.
Lines outside banks in Athens have become the new normal. The one outside a Piraeus bank branch near Neos Kosmos station in Athens was long on Tuesday -- 15 or so people waited to withdraw money. Katerina Drikou was one of them, waiting to get hold of her pension -- at least the part she is allowed to withdraw. It was the third time this week that she was at the bank.
People in the queue were calm. Drikou said that the bank holiday brought a renewed wave of solidarity among the Greeks, who are radically cutting down on spending. "Nobody buys tickets for the trains and subway," she said. "But people understand."
Greek crisis...in two minutes
CNNMoney (Athens) First published July 8, 2015: 5:41 AM ET


text:
Posted inGovernment, News
Promised Library Hour Increase Is Delayed
by Lisa Halverstadt October 2, 2012 March 15, 2022
Earlier this year, San Diego Mayor Jerry Sanders announced a city budget surplus that would help increase library hours, including restoring Saturday service at Central Library.
That hasn't happened yet, even though the City Council approved a budget that included expanded hours more than four months ago.
The city's Independent Budget Analyst says that's because of Proposition B, a recently approved citizen initiative that calls for the city to offer new staffers 401(k)s rather than the pensions that have plagued the city's budget.
San Diego officials had to develop an interim plan to provide retirement benefits for new employees and reach an agreement about it with the city's five labor unions. That meant delaying the hires necessary to expand library hours, said Chris Ojeda of the budget analyst's office.
"They were looking at additional hours but additional hours are going to necessitate additional bodies," he said. "(Extended library hours) are going to be delayed until that hiring freeze is lifted."
The freeze has also affected other city departments, including parks and recreation. It also threatened to prevent 36 fire department recruits from attending a fall academy, U-T San Diego reported last month.
But library lovers are in luck.
The City Council on Monday unanimously approved the interim retirement plan for new employees.
That vote means residents can enjoy Saturdays at the Central Library and an uptick in hours at branch libraries sooner rather than later. A 2013 budget overview says the downtown library, which eliminated its Saturday hours in 2010, will be open a portion of that weekend day and that hours at the city's 35 branch libraries would increase to 44 hours each week, up from 36.
The city now expects to have the necessary staffing to open the Central Library from 9:30 a.m. to 2:30 p.m. on Saturdays beginning Nov. 3 and add more Sunday hours at other city branches the following day, a library spokeswoman said.
The city will still need to recruit and hire more staffers to increase its Monday hours at multiple city branches and hopes to have that done by early December, the spokeswoman said.
Lisa Halverstadt is the newest reporter at Voice of San Diego. Know of something she should check out? You can contact her directly at lisa.halverstadt@voiceofsandiego.org or 619.325.0528.
Follow @@LisaHalverstadt
Follow @voiceofsandiego
Like VOSD on Facebook.
Tagged: Budget Cuts, Central Library, City Council, Independent Budget Analyst, Jerry Sanders, Library Hours, San Diego Libraries
Lisa Halverstadt
Lisa is a senior investigative reporter who digs into some of San Diego's biggest challenges including homelessness, city real estate debacles, the region's... More by Lisa Halverstadt


I do love Ponderosa Pines with their coarse red bark, long green clumps of needles, and gnarly-shaped branches. Wild Horse Island is loaded with them. Since their fallen needles discourage undergrowth, a forest of them can take on an enchanted look—particularly in the twilight hours.
Here is a great kayak route that Marlene and I took in Glacier National Park. It was a short scenery packed morning trip from Swiftcurrent Lake up the connecting creek (and back) to Lake Josephine.


text:
Berkeleyside blotter: Crime in Berkeley, Dec. 24-30
Homeless man pepper sprayed by a stranger on College Avenue, adult film star arrested after kidnapping and assault report, driver in stolen tow truck evades CHP in high-speed chase, stolen South Berkeley mailbox to be replaced, and more in this week's crime blotter.
By Emilie Raguso Jan. 8, 2016, 1 p.m. March 6, 10:01 a.m.
Selected calls to the Berkeley Police, via CrimeMapping.com. Scroll down for detailed maps. Click the map above for the list. See the map key here.
This overview of recent crime in Berkeley is based on reports to the Berkeley Police unless otherwise noted. Share photos, videos and tips, about breaking news or neighborhood safety issues, via email at crime@berkeleyside.com or on Facebook or Twitter. Don't assume someone else will alert us. We want to know about issues of concern and rely on readers to help us stay informed.
From Dec. 24-30, there were reports of four robberies, 18 burglaries, 13 assaults or batteries, no weapon-involved calls and no sexual assaults, according to CrimeMapping.com. There were also 10 stolen vehicles, six disturbances and 24 auto break-ins or thefts from vehicles reported. No significant incidents were reported by the University of California Police Department (UCPD). The following items represent a sampling of calls; incidents that took place during a range of time are listed unless otherwise noted by the beginning of that time period.
Five vehicles were stolen: at 2:35 a.m. in the 2200 block of Stuart Street; at 3 p.m. in the 2700 block of Dana Street; at 5 p.m. in the 1600 block of Channing Way; at 5 p.m. in the 1000 block of Overlook Road; and at 10 p.m. in the 400 block of Northampton Avenue.
There were three robberies: at 3 a.m. at Ashby and Hillegass avenues; at 10:50 a.m. at Shattuck Avenue and Kittredge Street; and at 6:20 p.m. in the 1400 block of Shattuck Avenue. Police arrested 22-year-old Thomas Cullens in connection with the third incident; he remains in custody at Santa Rita Jail and has already been sentenced.
There was a home burglary at 4 a.m. in the 1900 block of Ward Street.
There was a disturbance at 12:20 p.m. in the 2600 block of San Pablo Avenue.
There was a felony assault or battery at 5:15 p.m. in the 2200 block of Shattuck Avenue.
There were 18 burglaries (shown in black) reported over this period, via CrimeMapping.com. The prior week there were 23. There were also four robberies (in blue), following six the prior week. Click the map for a list.
There were two home burglaries, at 1 a.m. in the 1800 block of Thousand Oaks Boulevard, and at 7 a.m. in the 1500 block of Alcatraz Avenue.
Two vehicles were stolen, at 5 p.m. in the 200 block of Marina Boulevard, and at 8:15 p.m. in the same block.
There was a robbery at 9:58 a.m. in the 2100 block of Kittredge Street.
There were two disturbance calls, at 4 p.m. in the 2300 block of Spaulding Avenue, and at 6:52 p.m. in the 3200 block of Sacramento Street.
A vehicle was stolen at 10 p.m. in the 2400 block of Oregon Street.
There was a commercial burglary at 10:46 p.m. in the 900 block of Murray Street.
Shown above: assaults or batteries, weapon calls, sexual assaults, arsons and disturbances. Click the image for a list. Source: Crimemapping.com
There were four home burglaries: at 12:01 a.m. in the 2800 block of Benvenue Avenue; at 1 a.m. in the 2700 block of Piedmont Avenue; at 10:30 a.m. in the 200 block of Tanglewood Road; and at 10:30 p.m. in the 900 block of Hilldale Avenue.
There was a disturbance at 3:20 a.m. in the 1200 block of University Avenue.
A 78-year-old Berkeley man was killed in a fire Sunday morning. The Fire Department was notified of a blaze in a home at 2817 Acton St. between Oregon and Russell streets at 4:47 a.m., according to Interim Deputy Fire Chief Donna McCracken. Flames were shooting from the home's windows when firefighters arrived. Billy Carroll, the man who died, was described by a former neighbor as "a very friendly man who used to roller skate around the neighborhood. He would often take out a telescope to look at the stars and invite people in the neighborhood to watch." Read more on Berkeleyside.
There was a commercial burglary at 2:30 p.m. in the 1300 block of Seventh Street.
A vehicle was stolen at 9:15 p.m. in the 2200 block of Shattuck Avenue.
There were five home burglaries: at 2 a.m. in the 2500 block of College Avenue; at 8 a.m. in the 2100 block of Oregon Street; at 3:45 p.m. at an unlisted location; at 6 p.m. in the 1800 block of Curtis Street; and at 11:30 p.m. in the 1800 block of Curtis.
According to the BART Police, someone tried to steal a black four-door 2004 Toyota Tacoma while it was parked at the Ashby BART station between 8:20 a.m. and 6 p.m. The thief "used a tool to remove the driver's door lock and broke a tool off in the ignition, attempting to start the vehicle," according to authorities.
There were 24 thefts or burglaries from vehicles, via CrimeMapping. There were 29 the prior week. There were also 10 vehicles stolen (in purple). Click the map for a list of incidents.
There were two home burglaries, at 4 a.m. in the 1700 block of Rose Street, and at 8:58 p.m. in the 1400 block of Edith Street.
There was a disturbance at 4 a.m. in the 1200 block of Colusa Avenue.
A stranger pepper sprayed a man sitting on the sidewalk near the Elmwood Cafe. Photo: Citizen reporter
At 10:10 a.m., a male sitting on the sidewalk in the 2900 block of College Avenue was pepper sprayed by a stranger, said Berkeley Police spokeswoman Officer Jennifer Coats: "Several witnesses reported the incident. The victim declined medical attention and did not want provide information" about what had taken place. A reader who initially told Berkeleyside about the incident said it happened outside the Elmwood Café at 2900 College Ave., adding: "we (customers) were coughing and ran out of the restaurant because some of the spray came inside." She described the victim as a "street person."
A vehicle was stolen at 11:30 p.m. in the 2800 block of Regent Street.
Police arrested 42-year-old Antara Mosley shortly after midnight on suspicion of assault with a deadly weapon. As of Thursday, Jan. 7, she remained in custody with a bail of $160,000 and had been scheduled for an attorney and plea hearing earlier in the day.
There was a disturbance call at 1:05 a.m. in the 1700 block of Virginia Street.
There were two commercial burglaries, at 3:39 a.m. in the 2900 block of Domingo Avenue, and at 3:43 a.m. in the 1700 block of Fourth Street.
According to the BART Police, a thief stole a gray 1990 Honda Civic while it was parked at the North Berkeley BART station between 2:10 p.m. and 5:15 p.m.
Other recent incidents
Dana and Carleton on Jan. 2. Photo: Citizen reporter
A 20-year-old adult film star from Berkeley was arrested Jan. 2 on a warrant for kidnapping in connection with an assault case from December. Berkeley Police spokeswoman Officer Jennifer Coats said the initial case took place Dec. 19 when a female victim told authorities her former boyfriend forced her to drive from Berkeley to Emeryville where he assaulted her. She "was able to get away" from the man, and contacted police, Coats said. The man fled prior to the arrival of officers, who sought a warrant for his arrest. On Jan. 2, officers learned the man was in the 2600 block of Dana Street, near Carleton Street, and arrested him at about 4 p.m. The man is no longer in custody but the case has been forwarded to the Alameda County district attorney's office for charging consideration, said Coats.
A South Berkeley mailbox stolen in December should be replaced this week, the U.S. Post Office reports. Several readers asked Berkeleyside about a missing mailbox at Adeline Street and Martin Luther King Jr. Way. USPS spokesman Augustine Ruiz confirmed this week that the box "was stolen in the evening after the mail was collected." He did not provide a date but a reader told Berkeleyside about the missing mailbox Dec. 7. Ruiz said the USPS is working to get a replacement "and we should get it installed by the end of this week." Ruiz said he did not know whether mail had been taken along with the box, adding, "If there was any mail in it, it would be from customers who may have dropped mail in it after the last collection, which is most unlikely because our customers know what time to deposit their mail before the last collection."
The California Highway Patrol chased a stolen tow truck in Berkeley early Thursday, Jan. 7, but terminated the pursuit when the driver reached freeway speeds on city streets, authorities said. Oakland CHP spokesman Officer Sean Wilkenfeld said the CHP got a call sometime before 4 a.m. about a stolen tow truck located on Gilman Street west of Interstate 80. Units responded, but the suspect fled before a roadblock had been established. The driver fled east on Gilman and continued for a short while, said Wilkenfeld, but "due to the suspect's excessive speed on city streets and reckless driving behavior we terminated the pursuit." Later in the morning, the tow truck was recovered after it had been abandoned in Oakland. Wilkenfeld said officers terminated the pursuit due to public safety, and noted that sirens were used "so that any pedestrians or vehicles in the area are aware of the danger and so that the suspect cannot later claim that they did not know we were behind them."
See the Berkeley Police Department's crime reports on CrimeMapping.com. See the list of calls to UC Police at Berkeley, which are also posted in brief on CrimeMapping, and UCPD crime alerts. See also Local Crime News' regularly published list of arrests of Berkeley residents. Other sources of information on crime in Berkeley include the Police Department's CrimeView Community and CrimeMapping.com. The Berkeley Police Department also posts "calls for service" spreadsheets — containing more data — online for those who would like to see more. New reports may be added to CrimeMapping in an unpredictable manner, so numbers may increase in the days after this report. This post does not reflect every call. See recent Berkeley crime blotters here.
Drugs tossed from car during CHP pursuit through Berkeley (01.08.15)
Woman dies in suicide near Berkeley's Old City Hall (01.07.15)
Community raises more than $31,000 for teacher hit by stray bullet (01.07.15)
2 arrested after West Berkeley carjacking, robbery (01.07.15)
Defendant in 2015 Berkeley murder case headed to trial (01.06.15)
Berkeley school teacher shot in the face in Richmond (01.05.15)
Berkeleyside blotter: Crime in Berkeley, Dec. 17-23 (01.05.15)
Power restored to 5,800 in Berkeley after outage (01.04.15)
Do you rely on Berkeleyside for local news? Support independent journalism by becoming a Berkeleyside member for $10 a month or even less, or by making a one-time donation.
ArsonBART PoliceBerkeley PoliceUniversity of California Police Department


PRODRG will take a description of a small molecule (as PDB coordinates / MDL Molfile / SYBYL Mol2 file / text drawing) and from it generate a variety of topologies for use with GROMACS, WHAT IF, Autodock, HEX, CNS, REFMAC5, SHELX, O and other programs, as well as energy-minimized coordinates in a variety of formats.
Please note that this server is strictly for academic use (max 5 submissions/day) only. For more extensive or commercial use you can obtain your own copy of PRODRG.
A list of some frequently asked questions is available is available, please have a look at it if you are having problems with PRODRG's output. If that does not help, or you have other comments/suggestions, feel free to email Daan van Aalten.
A. W. Schüttelkopf and D. M. F. van Aalten (2004). "PRODRG: a tool for high-throughput crystallography of protein-ligand complexes", Acta Crystallogr D60, 1355–1363.
Copyright © 2010-2019 GlycoBioChem Ltd.


text:
Q: Что с календарем? У меня есть переменная календаря и число long которое соответствует дате в миллисекундах. Я пытаюсь установить в переменную календаря эту дату.
В описании переменных, до onCreate объявлено Calendar calendar_1;
затем в onCreate я достаю сохраненное число и пытаюсь установить его в дату:
prefs = PreferenceManager.getDefaultSharedPreferences(this);
calendar_1.setTimeInMillis(prefs.getLong(pref_cal_1, 0));

Но вылетает ошибка, мол я пытаюсь применить метод .setTimeInMillis на null object
Если написать вот так:
prefs = PreferenceManager.getDefaultSharedPreferences(this);
calendar_1 = Calendar.getInstance();
calendar_1.setTimeInMillis(prefs.getLong(pref_cal_1, 0));

то все работает. Никак не могу понять суть проблемы, разве getInstance не устанавливает текущее значение? он же не нужен тут если я хочу свою дату установить.

A:
Но вылетает ошибка, мол я пытаюсь применить метод .setTimeInMillis на
  null object

В этом и есть суть проблемы - вы не инициализировали объект calendar_1. Для этого всегда требуется вызывать метод Calendar.getInstance()

P.S. тут об этом написано

redpajama_set_name: RedPajamaStackExchange


text:
Announcement: Rescue, by Pelaam
March 17, 2016 by scott
QSFer Pelaam has a new fantasy book out:
When prince Adrianus accepts a quest to find the Jewel of Darkness to break a curse on king Thanos's daughter, he takes along Fedor, a young man recently rescued from Thanos's stables.
Fedor has experienced much hardship in a short space of time. A slave in the stables of king Thanos, he's ill-treated by a sadistic captain of the guard until rescued by a royal visitor from another kingdom.
From a mix of gratitude and attraction he insists on joining Adrianus, despite the dangers involved. When he's captured as a sacrifice, he hopes his prince will come to his rescue once again.
When Adrianus finds Fedor, they realize their love, but this is only the start of their quest. Danger dogs their every step. But their deadliest danger is much closer to home than they know.
Adrianus wandered off to look around the palace stables, leaving Leonid talking with Sandor. Well bickering would be more accurate. He smiled grimly. His friends were as different in outlooks as they were appearances. He'd never known two people who disagreed on so much, got into one another's faces so often, and yet remained such staunch friends.
Then his attention was on the animals around him. King Thanos certainly knew his horse flesh. These were some of the most magnificent beasts he had ever seen. He moved forward, patting the neck of a couple of the horses as he walked slowly. They were clearly well looked after.
Whoever works in the stable takes good care of grooming the beasts, and cleaning their stalls. His own three horses' coats gleamed. They were fed and looked comfortable in their surroundings, despite the long ride.
A muted cry of pain drew his attention toward the recesses of the stable, and he strode quickly forward to investigate.
"Hurry, you useless fool."
The voice was harsh, cold, and set Adrianus on edge. Peering around a corner, Adrianus saw a big, brutish man flick a whip over the back of a stable boy who wore only an old, tattered cloth around his waist. Even without his headdress, Adrianus recognized the man as Drakos, the captain of Thanos's guard who'd been present when he and the others had entered the throne room.
While the stable boy was trying to move a sack of feed, clearly too heavy for his slender build, the sadistic sneer on Drakos's face told Adrianus the true story. Fury boiled over into action and Adrianus stomped over. "I see no need for using a whip on a defenseless boy. Perhaps you would care to try your luck with me?"
Drakos turned quickly, his lips drawn back in a snarl, and his whip at the ready. However, he froze when he saw Adrianus.
"Or even with me."
At the low and deadly tone of Leonid's voice, Adrianus allowed himself a grim smile at Drakos. "Perfect timing, my friend." He nodded at Leonid as his friend came to stand at his shoulder and then looked back at Drakos. "I'm sure that one of us will be a far more suitable challenge." He fingered his sword.
The big man backed away a step, caught the stable boy by his upper arm, and shoved him so hard that the young man lost his footing and stumbled to fall at Adrianus's feet. "Take him, if he's that important to you. It's easy enough to find any number on the streets that'll take his place."
The action took Adrianus by surprise. He hadn't actually thought of the consequences. He glanced down at the young man and suppressed a gasp. The stable boy wasn't as young as he'd thought, but he now gazed down at a face of incredible beauty. The youth's smooth, creamy skin and lithe, elfin body made him appear young, but gazing at his face, Adrianus estimated him to be well out of his teens and much closer to his mid-twenties.
Offering a reassuring smile as the stable boy looked up at him with fear in his large, dark eyes, Adrianus held out his hand. "Come here, boy. You are no longer a stable hand." He glanced over at Sandor, who had remained in the stable doorway.
Raising his arm, Sandor nodded. "Go with him." Adrianus pointed toward his mage. "His name is Sandor, and he'll take care of you." Perhaps he can serve Ruh and Sandor. But I won't leave him here.
The youth glanced towards Sandor, back up at Adrianus, and then slowly got to his feet. His tight, tense, body language screamed his fear, but he bowed at Adrianus before he scurried off.
"King Thanos will hear of this." The words were uttered in a deep growl. Drakos's hand hovered by his own sword, but he made no move to take it.
Waving his hand on which he wore Thanos's ring, Adrianus curled his lip. "Indeed he will. From me." Adrianus took a step forward and glowered at Drakos. "I understand him to be a fair and just man."
Staring at Adrianus for a moment, Drakos bared his teeth before moving cautiously around him and hurrying away.
"What are we going to do with the boy?" Leonid asked as he drew close to Adrianus. "You do realize Thanos may not let you take one of his slaves?"
"I don't know, but if he wants me undertaking this quest, he won't refuse me. Don't ask me to explain it, Leonid, but I'm not leaving him here." The idea of leaving the youth behind appalled Adrianus. Not going to happen.
"All I'll say is that I think you're making a mistake. The boy doesn't belong with us. He'll cause problems." Leonid folded his arms as if daring Adrianus to contradict him.
Evernight Publishing: Click Here
Amazon: Click Here
Living in clean, green New Zealand, Pelaam is a best-selling, multi-published author of gay romance and erotic books. When not busy writing she can be found indulging in her other passions of cookery and wine appreciation.
Pelaam's book "On Dragon's Wings" was LR Café 2014 winner for Fantasy. "Future Impefect" was a finalist for the 2015 Rainbow Awards in Gay futuristic/sci-fi. "Breath of the Feathered Serpent" was a finalist for the 2014 Rainbow Awards in Gay futuristic/sci-fi. "Bedazzled" and "Firebird" were a combined finalist for the Rainbow Awards in Gay futuristic/sci-fi 2013.
Facebook Profile: https://www.facebook.com/pamela.pelaamone
Facebook Author Page: https://www.facebook.com/pages/Pelaam/1467778320131583?ref=hl
Categories Announcements & Guest Posts, Fantasy, Romance Tags fantasy, LGBt fiction, mm romance, pelaam, Rescue Leave a comment Post navigation
For Readers: Judging It By The Cover
"2001" Promo Looks at Life in The Future


Step 1: When Timeout with the ScreenLock option is enabled, Internet, camera and FaceTime are disabled. Also - the device will re-lock the screen even if unlocked by the child.
The first step is to log in to the Netsanity Parental Dashboard.
Step 3: Click Manage Child next to the child you would like to put in Timeout with ScreenLock.
Step 4: In the left-hand menu, click Preferences.
Step 5: Click the dropdown menu to see your choices for Timeout.
Step 6: Select ScreenLock. You also have two other choices for Timeout preferences. You can choose to block 'just the internet' or hide all apps not pre-installed by Apple.
Step 7: Click OK on the Success Popup.
Step 8: Click the Timeout toggle so it is green. This will put the child's device in a Timeout with ScreenLock in just a few moments.
Step 9: To turn Timeout back off and allow use of the device, just toggle it back to the gray position. That's it. You're done!


Dr. G. Allen Power, a pioneer in dementia care, has just published a new book challenging most of the conventional wisdom about caring for those with Alzheimer's and other forms of dementia.
Ecumen Awakenings™ once again received national attention for its innovative approach to dementia care.
Mirzeta Huskic is a warm-hearted warrior in the day-to-day battle against dementia. She shares her challenges and joy.
The moving documentary, "Glen Campbell... I'll Be Me" tells the story of the Grammy Award-winning artist's battle with Alzheimer's and his farewell tour. The movie is in theaters in Minnesota, Missouri and Alabama today, Friday, October 31.
The Mankato Free Press in Mankato, Minn., writes about the expansion of Ecumen Awakenings to assisted living at this link.
Ecumen is proud to be a partner in the important work of reducing the use of unnecessary antipsychotic drugs in all Minnesota nursing homes.


text:
Home > Profile
Developing World Health
Contact's name
www.developingworldhealth.org
Scottish local authority
Stirling Council
Developing World Health has been established with the primary aim of addressing the need for new, safe and effective treatments for malaria, neglected tropical diseases such as trypanosomiasis (sleeping sickness) and related serious infectious diseases. It will build on the historic contribution and influence that Scottish scientists and physicians such as Dr David Livingston and Sir Patrick Manson have had in Tropical Medicine and the new aspirations of Scotland to make a national contribution to global poverty reduction and development (as evidenced by the Scotland:Malawi Partnership). ,,The aims of Developing World Health are to help develop new innovative treatments for malaria and several of the neglected diseases which affect the developing world, particularly Africa. We aim to fast-track new medical treatments primarily focusing on key areas of unmet clinical need, where current treatments are either, toxic, ineffective, or simply inaccessible.,
Location in Scotland
Church of Scotland World Mission Council
Dunblane Likhubula Link
Oban High School
LUV+ (Leprosy at Utale Village PLUS)


text:
5 Latin Autobiographies You Should Read ricky-martin-thal%C3%ADa-5-latin-autobiographies-you-should-read
Ricky Martin To Thalía: 5 Latin Autobiographies You Should Read
From successful entrepreneurs to salsa queens and Latin crossover kings, here are five must-read autobiographies by Latin musicians
Reading autobiographies serves as a great way to intimately learn something new about the background and career arc of your favorite celebrity. During our continued celebration of Hispanic Heritage Month, we've rounded up five autobiographies by Latin musicians worth looking into, spanning salsa legends, powerful entrepreneurs and Latin crossover stars.
Celia Cruz, Celia: My Life
A three-time GRAMMY and four-time Latin GRAMMY winner, Cruz's career was one for the history books. While we know the late Queen of Salsa intimately through her music, she kept the majority of her personal life story under wraps. In her 2004 memoir, Cruz finally let people in, sharing details on her childhood in Cuba, her years in exile in Mexico, and her career and life in America. The book is based on more than 500 hours of taped interviews shortly before her death in 2003 and provides a rare, intimate look into the life of one of Latin music's greatest treasures.
Emilio Estefan, The Rhythm Of Success: How An Immigrant Produced His Own American Dream
Having earned seven Latin GRAMMY Awards to date, producer Estefan knows a thing or two about success, which makes the title of his 2010 book, The Rhythm Of Success, particularly apt. Not only does the mastermind behind the Miami Sound Machine detail coming to America as a refugee from Cuba and becoming a successful entrepreneur, but he offers readers his hallmarks for creating a rich life and successful career — intuition, strong values and self-confidence.
Ricky Martin, Me
Martin started his career at age 12 in the boy band Menudo before he would go on to become one of Latin music's hottest stars, winning three Latin GRAMMYs. Despite his meteoric rise to fame circa 1999 during the Latin explosion with "Livin' La Vida Loca," Martin's personal journey offered its own challenges. Starting with his childhood in Puerto Rico through coming to terms with his identity, including his sexual orientation, and finally finding love and starting a family, 2010's Me offers fans an intimate glimpse into the pop singer's life straight from the man himself.
Rita Moreno, Rita Moreno: A Memoir
One of only a handful of artists, and the only Latin artist, to have earned the holy grail of awards achievements — earning an Emmy, GRAMMY, Oscar, and Tony — Moreno certainly knows a thing or two about excellence. In her 2014 New York Times best-selling memoir, Moreno takes us behind the curtain to her childhood in Puerto Rico. The book then follows her journey through discovering singing and dancing in the Bronx, N.Y., and her struggle to break down racial and gender barriers in the industry. It all makes for an epic tale populated by characters such as Gene Kelly, Gary Cooper, Elvis Presley, Marlon Brando, and Howard Hughes.
Thalía, Growing Stronger
Mexican singer/songwriter actress Thalía may be known as the Queen of Latin Pop, but that doesn't mean she rose to her throne without hardship and hard work. Appropriately titled Growing Stronger, Thalía's 2011 memoir doesn't shy away from the most difficult experiences in her life, including the loss of her father as a child, the kidnapping of her sister and a life-altering disease. The six-time Latin GRAMMY nominee also imparts her wisdom on gratitude, joy and finding balance for a truly inspirational peek inside the life of an international superstar.
Playlist: Celebrate Puerto Rican Musicians ricky-martin-luis-fonsi-11-songs-puerto-rican-artists
Ricky Martin To Luis Fonsi: 11 Songs From Puerto Rican Artists
From Latin GRAMMY winners Ricky Martin to Wisin Y Yadel, Farruko, Draco Rosa, and more, check out the signature sounds of your favorite Puerto Rican artists
Whether it's the sexy styling of Ricky Martin, the rock genius of Draco Rosa, the hip-hop vibes of Wisin Y Yandel, or the smooth grooves of Luis Fonsi, there's a lot of celebrate from our favorite Puerto Rican artists.
In honor of Hispanic Heritage Month, we have gathered 11 GRAMMY and Latin GRAMMY-winning or -nominated artists who hail from Puerto Rico and curated the perfect playlist you've got to hear.
1. Ricky Martin, "Vuelve"
2. José Feliciano, "Por Ella"
3. Rita Moreno, "Somewhere"
4. Victor Manuelle, "He Tratado"
5. Olga Tañón, "Es Mentiroso"
6. Ednita Nazario, "Llorar Por Ti"
7. Wisin Y Yandel, "Ahora Es"
8. Alexis Y Fido, "Una En Un Millión"
9. Farruko, "Obsesionado"
10. Draco Rosa, "Más Y Más"
11. Luis Fonsi feat. Daddy Yankee, "Despactio"
18th Latin GRAMMY Awards: Record Of The Year Poll luis-fonsi-maluma-who-will-win-record-year-latin-grammy
Luis Fonsi To Maluma: Who Will Win Record Of The Year Latin GRAMMY?
Cast your vote. Who will voters choose for Record Of The Year at the 18th Latin GRAMMY Awards?
Renee Fabian
Oct 1, 2017 - 9:57 am
Including the likes of Shakira and Carlos Vives to Natalia Lafourcade, Marc Anthony, Jesse & Joy, and Alejandro Sanz, the previous Latin GRAMMY winners for Record Of The Year reads like a who's who of Latin music. This year's nominees are no different.
Sep 20, 2017 – 10:53 am
Calle 13 Win Latin GRAMMY Album Of The Year
With Rubén Blades' sensual "La Flor De La Canela," Luis Fonsi featuring Daddy Yankee's song of the summer "Despacito," Residente's impactful "Guerra," Ricky Martin with Maluma's Vente Pa' Ca," and Jorge Drexler's "El Surco," among others, this year's class of 18th Latin GRAMMY Awards nominees for Record Of The Year is loaded.
Which song do you think will take home the Latin GRAMMY for Record Of The Year? Cast your vote below.
18th Latin GRAMMY Awards: Which song do you think voters will choose for Record Of The Year?
"La Flor De La Canela," Rubén Blades
"El Surco," Jorge Drexler
"Quiero Que Vuelvas," Alejandro Fernández
"Despacito," Luis Fonsi feat. Daddy Yankee
"El Ratico," Juanes feat. Kali Uchis
"Amárrame," Mon Laferte feat. Juanes
"Felices Los 4," Maluma
"Vente Pa' Ca," Ricky Martin feat. Maluma
"Guerra," Residente
"Chantaje," Shakira feat. Maluma
Take Note: Women In Music take-note-women-music
Take Note: Women In Music
Celebrate pioneers and heroes of the music industry
GRAMMY.com Staff
Take Note: We're celebrating, recognizing, honoring, and spotlighting women in music every day this month (and beyond). Visit GRAMMY.com daily for series updates.
Take Note.
Photo: Stefanie Keenan/Getty Images
See Ricky Martin In Extended Las Vegas Residency ricky-martin-extends-all-las-vegas-residency
Ricky Martin Extends All In Las Vegas Residency
The GRAMMY winner has announced he will extend his stay in the city an additional 12 dates in 2018
Dec 20, 2017 - 2:30 pm
Ricky Martin is "Livin' La Vida Loca" in Las Vegas since he announced an additional 12 dates to his residency there, adding dates between March 15, 2018, and June 3.
The GRAMMY winner has been performing his All In residency since April at Park Theater at Monte Carlo Resort and Casino in Las Vegas. Martin's show features 21 of his biggest hits, including crowd-pleasers such as "Livin' La Vida Loca," "Shake Your Bon Bon," "Cup Of Life," "La Bomba," and "Vente Pa' Ca."
The show isn't over yet! We're back again at @ParkTheaterLV
in 2018. Tickets go on sale Friday, 12/22 at 10am PST #RICKYALLIN pic.twitter.com/aRZgdSu9d3
— Ricky Martin (@ricky_martin) December 20, 2017
This announcement follows a Sept. 4 documentary on VH1 titled "Ricky Martin: Behind The Vegas Residency," which gave viewers all the behind-the-scenes scoop on the singer/songwriter's sold-out residency so far.
Tickets for All In's new dates go on sale Dec. 22 via Ticketmaster. Don't forget to grab yours!
Ricky Martin: Las Vegas Residency Special To Air


text:
Home » Newspapers » #special issue: Knowledge in Action /2008/ » Copenhagen Free University /// We have won!
Copenhagen Free University /// We have won!
In the spring of 2001 we demanded: All Power to the Copenhagen Free University. We had just opened a free university in our home in the Nørrebro district of Copenhagen. This impossible demand was put forward in the form of a manifesto intented to provoke and unsettle the collective imaginary and open new potential paths of action. We wanted to take power.
The manifesto was written in a very specific socio-political context preceding September 11th 2001. It was written in a mood of confidence. With the Copenhagen Free University we wanted to reclaim power and help undermine the so-called 'knowledge economy' – a term used to describe the new economy that was consolidating around the turn of the millennium. The unrolling of the knowledge economy was a part of the neoliberal campaign for control orchestrated by the financial and political elites and the term made clear what kind of ambition was at the core of this campaign: the financialisation of our brains, our nervous systems, our subjectivity, our desires, our selves.
In the midst of the unrolling of this economy, we intended to push the limits and develop new means to stem the invasion of our life by the abstract calculations of capitalist valorisation. It was our intention to picket the social factory, preventing an imminent and clearly hostile take over. We opened our flat as a space for social research and exploration within a context shaped by the hard material facts, fluctuating passions and affective instabilities that characterized our daily life. We wanted to turn the tide. We took power by using the available means: a mattress became a residency, the bedroom a cinema, the living room a meeting space, the workroom an archive, our flat became a university. Opening our private space turned it into a public institution. The Copenhagen Free University was a real collective phantom, hovering.
At the same time, many art workers in their hunt for a new function in society and new sources of income were getting involved in the corridors and boardrooms of the companies and corporations of the neoliberal economy. The artists acted as consultants and legitimators in branding and business activities relating to new ethical and social responsibility schemes and human resource management. The anger and hopes of the revolutionary avant garde had been deemed naive and artists were adapting to a new landscape of immaterial production. This told a sad story about society's lost ability to dream.
When turning to the education sector we saw that universities across the globe were increasingly restructuring and adapting to corporate practices. Ideas of autonomy and independence in research were quickly falling out of fashion. Not only was the usability of the knowledge produced in universities becoming a contested area, the distribution of intellectual property was becoming a key lever in the new economy. The Copenhagen Free University made it clear that universities do not necessarily have to reflect the hegemonic structures of society; universities could be organised and based in and around the everyday knowledge and material struggles structuring people's lives. Universities could in fact counter the hegemonic structures. We tried to open a new front at least.
By reclaiming one of society's central means of knowledge production, the machinery of the university, it was actually possible to create spaces that were not based on capitalist valorisation. For us 'free' mean gratis and liberated. Everybody can open their own university, it is a simple action. By self-organising universities people can, in a very practical way, counter the free market restructuring of the official universities by re-appropriating the concept of the university as a place for the sharing of knowledge among students (as the first universities were defined). With the Copenhagen Free University we wanted to break into the university as one of the imaginary institutions of neoliberal society and create a new image, and a new potential path of the possible.
Six months after we opened the CFU, 9-11 happened and the War on Terror pushed the anti-capitalist movement onto the defensive, having to react to all the emerging wars unfolding in the following years. The global civil war was invading our lives and imaginations. This broke the back of the anti-capitalist movement right after the victories of London, Seattle, Gothenburg and Genoa and turned it into the much more vague so-called Social Movement whose objectives became reformist and unclear. Despite this, arrays of de-centralised and self-organised initiatives were still developing and proliferating at grassroots level. Swarms of projects engaging in developing alternative ways of life, building on friendship, extending networks, and with clear cultural, social and political aims, were still coming into being. These community based initiatives were usually resisting formalisation and avoiding the spectacularisation of politics through the useless and pacifying academic seminars, art exhibitions and publications that have increasingly characterized the mediation of critical culture in recent years. We also checked into this circuit occasionally and got a taste of the forces that are producing schizophrenia and resignation in us.
During our life at the CFU we have encountered the way in which the authority of the word 'university' works on many levels. On a very practical level, people from across the globe started to write to us, applying as students and lecturers; people were using the CFU as a means of getting into increasingly privatized archives, people were using the CFU to obtain job references, people were using the CFU as a means to get into the fortified first world . . . These and other incidents make plain how embedded the authority of institutions is in the global imaginary. But it also tells us how fragile ruling power is when you play with its language and its basic definitions. The drive to self-determination despite the neoliberal knowledge economy was also demonstrated by all our sister self-organised universities that have mushroomed everywhere in parallel to our own development. It has never been about joining the CFU, or any other university, but about opening your own university.
One thing is the fact that a self-instituted university is messing around with the institutional power relations. But on a structural level the question is what conceptions of knowledge are actually pervading the self-institution? Knowledge for us has always been something that is evaporating, slipping between our fingers. It is not something that we treat as a truth or a possession but something living, a relation between people. Truth is always the truth of the masters, the proprietary knowledge is always the knowledge that separates people into those who posses and those who don't. Knowledge for us is always situated and interweaved with desire. The kitchen, the bed, the living room made up our anything-but-sterile laboratories. Dreams, unhappiness, rage were all over the architecture. Knowledge is at the same time about empowerment, making people able to understand and act closer to existence and despite the distortion of the spectacle. The research projects we initiated worked as invitations to share rather than drives to accumulate. There have been no singular end products; of importance were all the various experiences and conclusions that people carried into their own lives and networks after taking part in the activities at the CFU. This is why we haven't published papers or dissertations to wrap up the research projects that we have worked with. We found that the research and the knowledge spun at the CFU did not need a closure. But the institution did.
The Copenhagen Free University has never wanted to become a fixed identity and as a part of the concept of self-institutionalisation we have always found it important to take power and play with power but also to abolish power. This is why the Copenhagen Free University closed down at the end of 2007. Looking back at the six years of existence of the CFU we end our activities with a clear conviction and declare: We Have Won!
The CFU Abolition Committee of 2007 /
Henriette Heise & Jakob Jakobsen


Usually when making a build manually from inside Unity, I'd get an UAC prompt at that point. When running from TC, I don't get anything, and the command silently fails, returning nothing.
The build agent is currently set to run as a LocalSystem service. I've tried setting up the service to use a user account (with admin privileges): doesn't work any better.
I've tried disabling UAC entirely (as suggested here), doesn't work.
Please try to run agent via console, not as service. Does it help?
I didn't know about console mode, so thanks for that... but I just tried it, same result.
If I run the same command (copy-pasted from the build step log) in an admin command prompt (same user, same session, same everything), the package works flawlessly!
Could you please attach screenshot of the build step settings, the build log, all agent logs covering the build, the command you used in the console to run the build and the full console output of the build?
"C:\Program Files\Unity 5.2\Editor\Unity.exe" -projectPath "C:\TeamCity Server\buildAgent\work\1c3447956c64a79a\Seasons" -executeMethod Buildator.build -outputDir "C:\Unity Projects\SaF\Build\TeamCity" -buildNumber 13690 -changeset 862eac36e1e9 -target XboxOne -package -batchmode -quit -logFile "C:\TeamCity Server\buildAgent\work\1c3447956c64a79a\unity build.log"


Ivar had his fisher price nativity set out yesterday and I asked him what the king had in his hand. He looked at it and said, "Soup." I asked him what the other kings had in their hands. And he answered, "More soup."
Not a bad idea. I would imagine Mary would have appreciated some warm soup after delivering Jesus. Maybe more than gold. Warm soup after having a baby? Good thinking, Ivar.
**It should be noted that the above picture was staged by a 31 year old during nap time. At no time are these characters set up like this. Usually there is a garbage truck and a few tractors in the mix. Usually all of the nativity sets are mixed together so there are three baby Jesus'.
And in other exciting and thrilling news...my sister Annika is blogging again!!! Sort of. Actually, I am blogging for her. But her girls are so funny, she has stories every day, and I decided that I will post them for her just so they get written down. Click here to visit her blog.
When I asked Svea the same question about the gifts for baby Jesus, she replied, "A water bottle, cake and birthday cake".
We have that same nativity set! Ethan's only 9 months so he mostly just nibbles on the bumpy sheep and smashes around. The camel with the Donald Trump hair cracks me up.
off to investigate the hair on the camel!!!


text:
Q: I am getting error while training the ML model I'm trying to run the following code to train a model:
history = model.fit(train_ds,
          steps_per_epoch=train_len/20,
          validation_data=val_ds,
          validation_steps=val_len/20,
          epochs=50,
          verbose=1,
          callbacks=[cp_callback]
          )

but getting the error:
TypeError: Cannot convert 0.8 to EagerTensor of dtype int64

I am unable to train a model.

A: try to map steps_per_epoch and validation_steps using int function:
int(steps_per_epoch=train_len/20)
int(validation_steps=val_len/20)